(NOTE: Updated 20080120T161000-06. Modified “When” field to insert “offset” as second piece of data.)
Currently, I know of only two widely-used types of files that have a defined way of embedding geolocalization information:
- JPEG images may use EXIF GPS data fields to store a single ICBM Address, including elevation. This seems to be the only really common current use of embedded geotagging (for example, at Panoramio).
- GeoTIFF files can incorporate a wide variety of geographic metadata, but are primarily intended for professional or semi-professional GIS applications.
Given the huge variety of other file types that might contain a subject that can be usefully georeferenced, I think some format for specifying location information would be useful. Googling around the internet turns up a few references to other people wondering how to georeference other media, but little in the way of solutions.
Since most data formats seem to include space for arbitrary metadata (i.e. a “comment” or “description” field), I am attempting to define a simple, terse, human-readable, machine-parseable way of encoding basic location information that could be inserted into appropriate metadata fields of any arbitrary computer file, including audio (mp3, OGG/Vorbis, etc.), video (DivX, OGG/Theora, etc.), written word (ODF documents, PDF, etc.) or arbitrary text data (such as the GENBANK format for DNA and Protein sequences), still images (JPEG, PNG, GIF, etc.), web pages, etc., including formats that do not yet exist.
This is not intended to be a replacement for or a “competitor” to formats like GPX or KML, though the information from geostrings ought to be easily converted for use in such formats. The goal here is purely to provide enough information for the recipient of a file to plot associated points on a map from it.
I propose a format that I am calling “geostrings”. This format uses a single line of text to define a specific location, most commonly a point but potentially an area (as a polygon). The format only requires normal alphanumeric characters and periods, commas, colons, and minuses (“.”,”,”,”:”, and “-“). This should enable geostrings to be used even in very restrictive metadata formats which might forbid certain punctuation or other special characters.
To tag a file with a geostring, the relevant latitude, longitude, and optionally elevation are combined with an optional field which may contain a timestamp and/or a track designator and a third even-more-optional field potentially containing heading and inclination angles. This information is compressed into a single string beginning and ending with “geostr” and inserted into whatever space the tagged file’s format allows.
The fields (including the bounding “geostr” markers) are separated with colons, and individual data in each field is separated by commas. The result is organized roughly like this:
Only the “where” field is mandatory. Non-mandatory fields and data may either be left out entirely or may be left blank.
The “Where” field is mandatory. It must contain latitude and longitude (in that order), and may optionally include an elevation.
Some software seems to prefer the order “Longitude, Latitude”, presumably because that puts them in “x,y” order. I specify “latitude, longitude” instead here purely for human-readability. Most people speak of the coordinates in that order, so I would assume most people would expect to read coordinates in that order. Since the computer really doesn’t care so long as you’re consistent, “latitude, longitude” seems to make more sense in this case. Both latitude and longitude are purely numerical data in decimal format. (Negative latitudes for “southern hemisphere”, negative longitudes for “western hemisphere”.) The optional elevation is a decimal number, optionally suffixed by “f” or “m” for “feet” or “meters”. If no suffix is supplied, meters should be assumed.
For polygons (or line segments), multiple sets of three data (lat/lon/elevation) are included here. In this case they must be in sets of three, though the elevation in each case may be left blank (i.e. “90.00,-180.00,,90.00,0.00,,0.000,0.000,,0.00,-180.00,” defines a rectangle bounding the northwestern quadrant of the globe.).
The optional “When” field contains up to three bits of information – a timestamp in the ISO8601 Standard “simple” format, and an even more optional integer representing an “offset” in number of seconds for non-instant media (e.g. for when an audio or video file changes location after a certain period of time), and finally a yet-more-optional arbitrary alphanumeric string designating a “track”. If more than one geostring is included in a file, any geostrings sharing the same track designation are assumed to be part of a track (and ideally lines should be drawn between the points when they are rendered on a map). If no track designation is supplied, multiple points are assumed to be discrete from each other.
The third, most optional field may contain a decimal number from 0 to 360 for heading, and a second decimal number from -90 to 90, indicating inclination. On those uncommon occasions when these figures are supplied, they could be used in combination with the lat/lon/elevation to orient a view in, say, “Google Earth” or NASA Worldwind which corresponds to a view associated with the file in question.
This should be a point in Eastern Albuquerque, at ground level, on the morning of January 4th, 2008, looking east-northeast and upwards about 20 degrees. No offset time since this is an instantaneous “snapshot”, and no track designation because it is a standalone point.
Here’s a basic algorithm for parsing (examples in PHP and other languages to come soon):
- Isolate any text found between “geostr:” and “:geostr”
- Split this text using “:” as a delimiter.
- The first string returned by that split is the “where” field. Split this using “,” as the delimiter.
- If there are either 2 or 3 strings returned:
- The first string found is the latitude in decimal format.
- The second string is the longitude in decimal format
- The third string – if any – is the elevation. Check this for a final “f” or “m” character to determine whether this is feet or meters. “f” = feet. “m” or no suffix =meters.
- If there are 6 or more strings returned, in multiples of 3:
- This geostring represents a “polygon“.
- This should be parsed as multiple individual lat/lon/elevation points. When rendered, lines should be drawn between these points, including a line connecting the last and first points.
- The second string returned from the colon-delimited split – if any – is the “when” field. Split this using “,” as a delimiter
- The first string returned – if any – will be an ISO8601 “Simple” format timestamp. (In the unusual event that this point is part of a track but has no timestamp, this string will be blank)
- The second string returned – if any – is an integer representing an offset, in number of seconds, from the beginning of the tagged media to which the location in the geostring refers. For example, if a podcast has an interview with someone in one place at the beginning, followed by recording done at another location beginning at the 5:30 mark, the podcast’s ID3 comment tag might include two geostrings, the second having a specified offset of 330.
- The third string returned – if any – is an alphanumeric character representing a track ID. An array should be created in this case to keep all geostring points from the same track together. When rendered, lines should be drawn between the points, unless they are being rendered as an animation (in which case it’s optional).
- The third and final string returned from the colon-delimited split – if any – is the “whither” field. This should be split using “,” as the delimiter.
- This first string returned – if any – indicates a heading from 0 to 360 (0 or 360 = “due north”)
- The second string returned – if any – indicates an inclination from “parallel to the tangent of the Earth’s surface”, from -90 to 90. Negative numbers indicate “look down”, positive indicates “look up”.