• It relies on the receiving device having internet access. That is not a valid assumption. Some might argue that devices without internet access can’t display locations, but that’s not true. Many devices contain pre-installed maps, and others might choose to display the location with, say, a compass needle and distance counter.
• URLs are verbose. An SMS is limited to 160 characters, so every letter counts. The overhead for a Google Maps URL is http://maps.google.com/maps?q= or 30 characters, versus four characters for geo:. In theory you could set up a shorter URL, but you’d never get down to four characters.
• URLs change. We think of Google Maps as a permanent part of the internet’s infrastructure, but it’s only been around for five years. Some time in the future Google may go out of business, start charging for the service, or change the syntax.
• Google Maps URLs have no way to specify altitude or accuracy. Maybe you could set up a different mapping service that does take those parameters, but you’d have to make the website as reliable as Google, available around the clock and able to handle heavy loads.
• The receiving handset has no discretion over how to display the location. It will be displayed as a pushpin on an English-language Google Map, and that’s it. No way to show your current position as well. No way to show the rest of the geotagged message at the same time. And no way to display the direction and distance to the location.
• In general, a URL geotag is not unambiguously machine-readable. A parser may do a decent job of extracting the latitude and longitude from a Google Maps URL, but for arbitrary URLs it’s not possible to do this reliably. Why does it matter? Because there are applications where the location has to be processed by a machine. Imagine an SMS-a-Taxi service where you send your desired pickup location. A server on the back end has to be able to parse the location and route the SMS to the nearest available taxi without any human intervention.

The aim of geotagging is to transmit a location, but the function of a URL is to display one, which is a different thing. The URL only contains a view of the location, not necessarily the location itself. It’s the difference between sending someone a fax of a printed document versus e-mailing them the file. The fax might be human-readable, but it’s useless to machines. The file itself can be put to many uses.

So in conclusion, URLs are not suitable as a geotagging standard. If you really want to make sure that a receiving handset can display a location, use a proper geotagging standard such as geosms and include a URL. It’ll cost an extra 20-30 characters, but in the long run it will be more useful to the recipient.

Here are all the examples of GeoSMS we’ve come across -

1. The GeoSMS standard. That’s us. Our Android application is called I Am Here.
2. The Open GeoSMS Standard Working Group at the Open Geospatial Consortium. Their application is called OpenGeoSMSer.
3. The GeoSMS Android application, published by Geeksville Industries.
4. The GeoSMS Google Maps mashup that displays SMSes at their tagged location.
5. The GeoSMS HTML5 web application.
6. The geosms server-side application, part of the InSTEDD Golden Shadow project.
7. The GeoSMS 1.0 Java application for mobile. According to the blurb “Send and receive sms in your language. For example: Georgian, Armenian, Azeri,
   chinese etc.”
8. The geo sms blogspot blog. Not sure why it’s called geo sms. May geo has a special meaning in Urdu.

All very confusing. I’m thinking maybe we should have called our standard GeoTXT instead.

In early 2007 the E-TEN Glofish M700 was launched, one of the first GPS-equipped smart phones to hit the market. Bundled with the phone was an application called Location SMS that let you send your GPS coordinates in human-readable form.

Based solely on the screen shot, it seems to use the reader-friendly B DD:MM‘SS.SS“ format to represent the location.

The TrekBuddy application, which runs on Java-enabled GPS devices, has had an SMS capability since September 2006. The SMS format wasn’t officially published, but it was mentioned in a forum post -

$TBMYT,1179735361,5000.29965,N,01749.65780,E,Be quick*00

• Header $TBMYT or $TBIAH – TrekBuddy My You There or I Am Here
• Timestamp in secs (currentTimeMillis / 1000)
• Coordinates in the same format as in NMEA
• User message (ie. “Be quick” in this example)
• And end as NMEA (*00), but checksum is not implemented

The GeoSMS service was established by Coldbeans Software, a Moscow-based company, in November 2007. If you send an SMS of the form *location* message to +7909 921 3670 your message will be displayed on their on-line Google map at the specified location.

Although this is technically a published standard, the definition of location is “anything understood by the Google Geocoding API”. This means the receiving application needs an internet connection. It’s also not that accurate, unless you want to specify your location down to the street number. In which case, why bother with geotagging?

From the same group of Muscovites came another GeoSMS service in September 2009, part of their Geo Messages suite. This is an HTML5 application that lets you send your current location, formatted as a bit.ly-compressed Google Maps URL.

Google Maps URLs, to be honest, are probably the best way to send a location to another person given the currently-deployed handsets, since they have the best chance of being displayed correctly. But they aren’t suitable as a geotagging standard because they require the receiving device to have internet access, and they rely on a proprietary Google interface. The use of bit.ly has similar problems, plus it’s at the mercy of the Libyan government.

Finally, there’s the GeoSMS Android application, released by Geeksville Industries in March 2010. This application also uses Google Maps URLs to encode the location.

A message encoded with version 2 of their standard might look like this -

<GarminLoc>Meet me at Taco Bell<C>N 38.85847 W094.81600 <G>201000021ba1f800bc934600

The human-readable location <C>N 38.85847 W094.81600 is optional, so a minimal machine-readable message could be made quite compact. However, there is no mechanism for representing altitude or accuracy.

The machine-readable component of the message is quite interesting. The first 8 digits are administrative overhead, but the characters 1ba1f800bc934600 encode the latitude/longitude as a pair of hexadecimal 32-bit signed integers. Each integer has a value in the range [-2147483648, 2147483647], which is converted to degrees by dividing by 11930464.71

This is actually a very compact format. The location is expressed accurate to 7 decimal places in just 16 characters. To achieve a corresponding level of accuracy in a base-10 encoded latitude,longitude format you would need around 23. Unfortunately it’s not human readable (or backwards-compatible with version 1 of the standard), so it’s recommended that a human-readable location be included as well, which eliminates any compactness advantage.

There is a reference application called Open GeoSMSer, which is available for Android, Windows Mobile 5/6, Symbian S60, and the iPhone. Unfortunately the Android version is compiled under a pre-1.6 environment, so it won’t install on my HTC Tattoo.

Open GeoSMS messages are encoded using the following format -

GeoSMS/version;latitude;longitude;format;data

The latitude and longitude are encoded using NMEA0183 (a National Marine Electronics Association standard). Their format is DDMM.mmmm,H, where DD is degrees, MM is minutes, mmmm is decimal minutes, and H is the bearing (N, S, E or W). For example, the longitude 121.566277 would be encoded as 12133.9766,E

The format can be B (Basic), A (AGPS), E (Extended), P (Point of Interest), or Q (Query), and the data component of the message will depend on this format.

Here’s a sample message -

GeoSMS/2;2230.978,N;12123.566,E;E;My car has broken down

Let’s be honest, I don’t think this is a very good standard. There are four broad criteria that a geotagging SMS standard should satisfy -

1. It must contain location data. Latitude and longitude at a minimum, altitude and accuracy if possible.
2. It must be machine-readable. Software should be able to unambiguously spot geotagged messages from all the millions of SMSes sent every day.
3. It should be human-readable. Many messages will arrive on phones that don’t recognise the standard, so they should make sense to a human reading them as straight text.
4. It should be compact. An SMS is limited to 160 characters, so the location data should be represented in as few characters as possible.

Now, the Open GeoSMS format is certainly machine-readable, and it specifies latitude and longitude. But it performs poorly on the other criteria.

Leaving out altitude and accuracy looks like an oversight. When there’s no GPS signal, many smartphones estimate their location using mobile phone towers, which can have an accuracy of a kilometre or more. If you’re requesting a taxi or an ambulance for example, it’s very important to include an accuracy estimate so they know if the location is reliable. Altitude is less important, but might be useful for finding someone in a multi-storey building.

The use of NMEA0183 is a big mistake in my opinion. Compared with good old base-10 encoding it’s less compact, it’s much less human-readable, and it’s more difficult for software to parse (base-10 parsing is built in to all software libraries).

I also think the use of pre-defined formats (B, A, E, etc) is a mistake, since it forces the standardization of every possible application of geotagging up-front. Standards should confine themselves to a core requirement (embed a location in an SMS) and leave application-specific requirements to separate standards that build on it.

But as I said, it’s a work-in-progress, and these issues may be addressed by the time it’s finally ratified as a standard.

• Improved the font size on hi-res handsets
• Added the option of displaying distances in imperial units