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:
geostring:point:41.228063:-115.058119:1720.901m:20071115T143000-06:1:340:-5.0:geostring
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?