Proposed format(s) for geotagging arbitrary types of media

Yet more thoughts on geotagging – here’s what I’ve come up with so far.

The format needs to handle only two fundamental data types – points and polygons. It also obviously needs to handle “lines” or tracks, but those are made of “points”. Polygon, for my purposes, might be unnecessary and I’m not sure if I should leave it in. I’m reluctant to leave it out – that way you could easily georeference media to a building or field’s outline, for example. On the other hand, I’m trying to keep this format terse and concise – I’m not trying to merely embed .gpx or .kml files in things.

A “point”, as I am thinking of defining it here, is made of up to seven attributes (more or less in order of importance): a latitude/longitude pair, elevation, timestamp, track-ID, heading, and angle. A polygon is the same, except that it contains a list of at least three lat/lon/optional-elevation sets. It still only has a single timestamp, though, just like a “point”. I suppose in some odd cases one could even define a track as a series of polygons – defining the field of view in a video taken from the bottom of an airplane that’s taking off, for example.

Leaving aside the question of polygons for now, I’m envisioning two possible formats which I will arbitrarily name “geotag” (XML-type) and “geostring”(simple text) for the moment.

I picture a geotag entry looking something like this:

<geotag:point lat="41.228063" lon="-115.058119" elev="1720.901m" datetime="20071115T143000-06" trackid="1" heading="340" angle="-5.0">Metropolis Hotel</geotag:point>

In this format, the optional description of the point is between the opening and closing tags there. “lat” and “lon” might be better as a single “latlon” or “coord” attribute, with the latitude and longitude separated by commas (i.e. <geotag:point coord="41.228063,-115.058119">:</geotag:point>)

A “geotring” point might look something like this instead:


Not sure if the closing “geostring” is really necessary here, but it would make backwards-compatibility easier if fields were added to future revisions. As with the geotag, it might be better to treat the lat/lon pair (the only mandatory information for a minimal “point” definition) as a single field, so the minimal “geotag” example above done as a “geostring” would look something like: geostring:41.228063,-115.058119::::::geostring

Even as I write this, I find myself leaning towards combining the latitude and longitude into a single field, if for no other reason than it means each point only has one required field. Either way, I currently think the fields ought to be defined thus:

  • latitude and longitude are decimal degrees. Either may be prefixed by a + or – (lat: +=”Northern Hemisphere”, -=”Southern Hemisphere”, Lon: +=East, -=West) – if neither is there, + will be assumed. Latitude and longitude are required for every point.
  • Elevation may be suffixed by “m” or “f” (for “meters” or “feet”). If neither is specified, meters are assumed.
  • Timestamp is in the ISO 8601 “basic format”. If neither “Z” or an offset from UTC are specified, “the viewer’s local time” should be assumed (which is kind of silly, but it still would allow one to synchronize a track with, say, an audio recording or video.)
  • trackid is any arbitrary alphanumeric term with a maximum of, say, 16 characters (is that enough?) Any points with the same trackid are assumed to be part of the same track. If unspecified, the point is assumed to be unrelated to any other points (if any exist) that may be in the same file.
  • Heading is in decimal degrees from 0 to 360. This represents facing a particular (horizontal) direction from the point in question. “Which direction the camera was pointing” in the case of a photograph.
  • Angle is in decimal degrees from -90 to 90. This represents an angle above or below the current elevation at that point (for a picture, this would represent the upward or downward angle that the camera was pointing when the picture was taken.)

Hmmm, if I shorten “geostring” to “geostr” and either eliminate the “data type” field (“point”) or just reduce it to a single letter, that entire and complete “geostring” example would fit even into a single tiny 64-character comment field, if there are any file formats still floating around limited to that kind of small metadata size.

My main goal here is to make it easy to create files tagged with this information. So long as it’s easily read and not likely to get separated from the file it describes, using the data for anything ought to be easy, even if one has to do it “by hand”. As was mentioned on the “Into the Pudding” blog (found via the GeoRSS blog), having applications that can read metadata is useless if nobody’s putting the metadata in their files to begin with. If an acceptable format can be worked out, I intend to start making as much georeferenced information available as possible.

Who’s with me? Comments, suggestions, offers of patronage, anyone?

Published by


The Author is (currently) an autodidactic student of Industrial and Environmental microbiology, who is sick of people assuming all microbiology should be medical in nature, and who would really like to be allowed to go to graduate school one of these days now that he's finished his BS in Microbiology (with a bonus AS in Chemistry). He also enjoys exploring the Big Room (the one with the really high blue ceiling and big light that tracks from one side to the other every day) and looking at its contents from unusual mental angles.

3 thoughts on “Proposed format(s) for geotagging arbitrary types of media”

  1. Another option would be to create a small application that builds a KML file to store this information. You could use ExtendData to store things like Track, but the other elements are already present in KML. And use the atom:link tag to actually have the reference the file.

    This way you could then use any KML library or even Google Earth to do geographic searches and visualization of your geolocated files.

  2. I am planning to come up with some example code to convert geostring tag information to KML and GPX formatted information. The KML (or GPX) files themselves do not solve the problem though, since if they are the place where the geographic metadata is stored, it becomes necessary to make sure the files never become separated.

    What I’m trying to accomplish directly is more analogous to what EXIF does, embedding the GPS data directly in the file itself so that it is a lot less likely to be lost during transfers or copying.

    Taking this as an excuse to inject some microbiology back into the blog, geostrings are analogous to genes, encoding some information, while the KML or GPX file would be more like the expression of that gene, the information being translated into a directly useful product…

Leave a Reply