thoughts-on-extending-the-geo-microformat

Thoughts on extending the geo microformat

Editor/Author

DimitriosZachariadis 17:03, 23 Jan 2007 (PST)

Introduction

The need for inclusion of altitude, time and reference system in the geo microformat is discussed. A five part value, semicolon separated, is argued to be sufficient for uniquely identifying a place or an event in a four dimensional universe.

Spacetimes are the arenas in which all physical events take place — for example, the motion of planets around the Sun may be described in a particular type of spacetime, or the motion of light around a rotating star may be described in another type of spacetime. The basic elements of spacetime are events. In any given spacetime, an event is a unique position at a unique time. Examples of events include the explosion of a star or the single beat of a drum.Spacetime, Wikipedia (annotation by the author)

 

LOCATION and geo referencing microformats proposed on this site, namely geo, luna and mars have at present a status of draft. With this in mind, a number of issues regarding the need for time and a reference system are presented for discussion.

Time

In a four dimensional space, a point represents an event; three dimensional geometry, cartography, and time, can all be thought of as subsets of spacetime; a location on a map is expressed in a 2D spacetime subset, a photograph in a 3D subset where time is the 3rd dimension.

It can be argued, that most of the location related information, whether on Earth or on another celestial body, have a time related aspect attached; historical places and events, geographical features, are usually related to an act or an observation made at some point in time. Landmarks existing for centuries have an age, which means they have a birthday, and most probably a death. Photographs and videos can be thought as 3D snapshots (2D+time) in a 4D continuum.

A large amount of location information used by people on a daily basis on the web, is in fact an aggregation of events; stories, news, photographs and videos, even items auctioned on ebay are nothing more than snapshots of spacetime. As such, most of this information can be accurately tagged, stored and used for as long as it exists, if its spacetime dimensions are known.

It is obvious that the inclusion of a time dimension in the geo markup moves the focus of geo tagging from the realm of two dimensional cartography to the realm of events; events are about stories, cartography is about navigation. People are interested in stories, news and events, which undoubtedly constitutes most of the information viewed with a web browser; few people can successfully navigate a car using a map and even fewer are interested in navigation and cartography as a science or art. Geographic coordinates shown in texts are quite useless without a map. Humans use names to identify places, not numbers. The reason geographic coordinates exist in text, is merely to help humans manually identify places on maps. If things can be done electronically, then numbers don't seem to matter a lot any more.

Real world examples

Countless examples of 2D+time events exist:

• flickr: geotagged photos with a date of capture.
• youtube: videos with a location and a date.
• wikipedia, In the news: front page news, "On this day..."
• BBC: news
• Mars As Art
• NASA: Explore Mars: space exploration vehicles, celestial body features, Missions
• Cassini imaging

Examples of loose, or changing, attachment of time to location also exist:

An example from ebay is indicative:

End time:	Jan-29-07 06:18:15 PST (6 days 21 hours)
Shipping costs:	US $1.88
                US Postal Service First Class Mail®
                Service to United States
                (more services)
Ships to:	Worldwide
Item location:	Dinwiddie, Virginia, United States
History:	0 bids

Different times

Dealing with time in multiple reference systems is not quite the same as dealing with local time. It might not be necessary for humans to do it in their daily life, but it is important when when information on a global, or universal basis is involved. Different cultures, use different reference systems to tell the time. Islamic calendar,Hebrew calendar, Egyptian calendar.

In a similar manner, trying to understand Martian time, while living on Earth, involves more than a simple addition/subtraction of a few hours. A Martian day, is not of the same duration as a Terran day, and the same is true for the duration of the seasons; a human cannot get a "7 hours behind local time" sync with Martian time; a number of connotations, that would otherwise help in getting a gut feeling, fail helplessly.

Different calendars and time standards should have a place in the Semantic Web.

The reference system

Although the geo microformat specification states WGS84 as the reference system used, this is not a trivial issue: Only 20 years ago, the same coordinates would possibly point hundreds of meters away from a location, since the reference system used at that time was different than WGS84. Furthermore, the same coordinates may not be accurate 10 years from today, when the WGS84 reference system will have been revised once again. Besides this, there is a number of other coordinate systems that are used extensively today, like the Universal Transverse Mercator (UTM) system, that are excluded from the geo specification. The problem is that tying a microformat specification to a particular reference system, and only that, may be a limiting factor for the microformat.

A markable indication of the importance of the reference system, when expressing geo coordinates, is the fact that the Greenwich Observatory, which was by definition the origin for the longitude coordinate for more than a century, lies now about 102.5m West of the WGS84 0.0 meridian, at N 51° 28' 36.71, W 0° 0' 5.18", (in WGS84 datum) according to Wikipedia, Prime_Meridian. Interestingly, Google maps and Wikipedia do not seem to agree on these coordinates (map)

When geo tagging information about other celestial bodies, the need for a reference system is even more pronounced; lacking familiar country or city names makes feature identification a difficult task. Existing reference systems are bound to change many times, as more data becomes available for these bodies.

For a microformat to be able to convey accurate information, well defined and known reference systems should be specified together with the data. Geo reference systems, such as WGS84, also make references to the time standard used WGS84 Definition. Transformations among the various reference systems can make content referenced by geo data in one system understandable and usefull on another.

Thoughts on specification extension

The geo microformat as it stands today, offers a representation of a point in a 2D space. Both expanded and compact forms of geo provide decimal number representations of coordinates suitable for machines.

Expanded form

The new properties to implement the additional dimensions of altitude and time could be:

• dtstamp, as found in hCalendar
• altitude, or the z direction
• georef

The dimension of time could be represented by reusing the dtstamp property found in hCalendar. The calendar to be used, depends on the reference system, and for WGS84 is the Gregorian calendar.

The dimension of altitude could be represented by the use of an altitude property, expressed in the WGS84 reference system in meters.

The georef property is a string determining the reference system, e.g. "WGS84". Additional fields could be allowed with the use of the delimiter ":", e.g. "MARS:J2000" (fictional).

Compact form

The value of an extended geo location/event resides in the title attribute of an (X)HTML element as a semicolon separated 5-tuple:

v1;v2;z;t;u  where:

v1 is either latitude or x, depending on u
v2 is either longitude or y, depending on u
z is the altitude
t is the time
u is the reference system code

The original form lat;lon is a valid form. To disambiguate this data, the reference system used in this case should have been specified globally for the page.

Dimensions z, t, and u can be omitted if they are at the end of the tuple. However, if omitting the z and t dimensions but defining the u dimension, then the relevant field values must be left empty, e.g.: v1;v2;;;u.

Dimensions v1 and v2 could also theoretically be omitted, e.g. 23.5 may represent the tropic of Cancer, ;0.0 the Greenwich Meridian, while ;;;2007 expresses the time (assuming a WGS84 reference system), although the latter could be better represented by a dtstamp property. However, such representations are obscure and do not add to the clarity of the data.

Default Reference System

The vCard, RCF2426 specification, which has been the basis for the geo microformat, does not specify a reference datum, but it specifies ISO-8601 as the standard for the UTC-OFFSET value type used in the TZ (timezone) type. hCalendar uses ISO-8601 (date)time formats.

The reference system specified by the geo microformat is WGS84. WGS84 in turn uses UTC to count (date)time which is based on the Gregorian calendar. It should be possible for the reference system to be explicitly stated either globally or within the geo data tuple. Units for data in the geo microformat are those specified in the reference system used.

Meta data

The default reference system could be set, using the name and content attributes of the meta (X)HTML element, as follows:

<meta name="georef" content="reference-system"/>

Default coordinate values

Only the z dimension (altitude, in WGS86) when omitted assumes a 0.0 meters value.

The default reference system for an (X)HTML page should be set by using meta data properties, if the geo data tuple defines no reference system. The inclusion of the meta data element ensures the validity of the spacetime data for as long as the page exists, while keeping geo values compact. By adding the georef metadata property, a transition to the extended geo microformat would require no further change to the markup.

Significant digits

A human reader interpretes the number of signifficant digits given in a number as a measure of the accuracy of the number. The number of significant digits in the coordinates could be related to the scale that a particular cartographic (or other) representation of a 4D point should be rendered in.

An application could use this expression accuracy, e.g. the number of decimal digits present in a coordinate to derive the zoom factor for a map showing the specific location.

Reference systems

Other reference systems include:

• UTM:zone
  • v1 is x, expressed in meters
  • v2 is y, expressed in meters
  • t is expressed in ISO-8601
  • zone is the UTM zone

...more

Examples

Example 1

Hidden 4D coordinates, no content

The Parthenon was ruined by a Venetian cannonball in 1687
<abbr class="geo" title="37.971508;23.72658;;1687">

Example 2

Hidden 2D coordinates and georef, free text content, expanded form

<span class="geo">
    The Parthenon was ruined by a Venetian cannonball in 
    <abbr class="dtstamp" title="1687">1687</abbr>
    <abbr class="latitude" title="37.971508"></abbr>
    <abbr class="longitude" title="23.726580"></abbr>
    <abbr class="georef" title="WGS84"></abbr>
</span>

may be rendered as:

The Parthenon was ruined by a Venetian cannonball in 1687

The same in compact form:

<span class="geo" title="37.971508;23.72658;;1687;WGS84">
The Parthenon was ruined by a Venetian cannonball in 1687
</span>

Example 3

Visible 4d coordinates

<abbr class="geo" title="37.971508;23.72658;;1687;WGS84">N 37° 58' 17.43, E 23° 43' 35.69</abbr>

may be rendered as:

N 37° 58' 17.43, E 23° 43' 35.69

Example 4

Minimal HTML page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="georef" content="WGS84"/>
  </head>
<body>
  <div class="geo" title="51.476864;-0.000518">
  The Greenwich Observatory
  </div>
</body>
</html>

Example 5

A fictitious Mars reference system, using Mars coordinates from Google Mars:

<span class="geo" title="18.302380;-133.472900;;;MARS:J2000">
Olympus Mons, Mars: The highest mountain in the solar system.
</span>

rendered as:

Olympus Mons, Mars: The highest mountain in the solar system.

Implementation example

A page with the above examples and a minimal javascript helper, opening a Google map in a separate window, using the number of significant digits as a guide for the zoom:

Only for Firefox at the moment:

Extended geo format examples

Notes

1. Umberto Eco, A Theory of Semiotics, 1976
2. RFC2426
3. W3C, Date and Time Formats
4. Wikipedia, ISO-8601

Further discussion

Comments and criticism about this page: