Posted on May 16, 02010
Filed Under Inspiration, Journal, Timelines | Leave a Comment
There was a time when predicting the future was the sole domain of mystics, auguries and madmen. Before the enlightenment it was commonplace for a ruling monarch to consult their court astrologer prior to making a decision. Knowledge of the future has always held a powerful allure and these days prediction is big business.
Everything from the markets to the weather is modeled and analysed, but until recently little historical data has been publicly available on the web. Tim O'Rielly, in his treatise on The State of the Internet Operating System, made an astute observation about the general lack of temporal data driven services.
"Time is an important dimension of data driven services - at least as important as location, though as yet less fully exploited. Calendars are one obvious application, but activity streams are also organized as timelines; stock charts link up news stories with spikes or drops in price. Time stamps can also be used as a filter for other data types (as Google measures frequency of update in calculating search results, or as an RSS feed or social activity stream organizes posts by recency.)"
The advent of open data is paving the way for a new kind of online service. Recorded Future brands itself as the world's first temporal analytics engine. Their technology mixes historical search with statistical analysis to make predictions about the future. The results were impressive enough to land investment from Google Ventures making this technology in every sense, the search engine of the future.
Posted on April 23, 02009
Filed Under DaVinci, Development, Drake, Flash, Journal, Projects, Timelines | 1 Comment
The demo above attempts to locate your current position on the earth. I can't take any credit for the 3D stuff as I based it on Andy Zupko's great post about Geolocation in Papervision3D. My little contribution is the code below. This takes the humble Date class and does some reverse engineering on it to derive your approximate location on the earth. First the code, then I'll explain how it works...
// Estimate Latitide and Longitude from the Date class.
var latitude:Number
var longitude:Number
var now:Date = new Date()
var northernWinter:Date = new Date( 2000, 0, 1 )
var northernSummer:Date = new Date( 2000, 6, 1 )
var northernWinterOffset:Number = northernWinter.timezoneOffset
var northernSummerOffset:Number = northernSummer.timezoneOffset
// Find just the Timezone modifier TZD (in minutes).
// DST modifier is negative so TZD is the larger value.
var tzd:Number = Math.max( northernWinterOffset, northernSummerOffset )
// if you need the current value of DST (in minutes) it's...
var dst:Number = now.timezoneOffset - tzd
// Estimate Longitude:
// 60 minutes of time == 15 degrees of longitude.
longitude = tzd / -4
// Estimate Latitude:
// If DST is adopted we can detect the current season and from that we can find the hemisphere. If not assume equatorial.
if ( northernWinterOffset == northernSummerOffset )
{
// equatorial
latitude = 0
}
else if ( northernWinterOffset > northernSummerOffset )
{
// northern hemisphere
latitude = 45
}
else
{
// southern hemisphere
latitude = -45
}
// and the estimates are...
trace( "Longitude: " + longitude )
trace( "Latitude: " + latitude )
Last year I wrote a series of posts that looked Inside the AS3 Date class. One of the gotchas I mentioned was the confusingly named .timezoneOffset property which is actually comprised of two offsets: timezone designation (TZD) and Daylight Saving Time (DST). In the article I showed some code that split these values back out again. Well it struck me the other day that you can use these values to approximate a users position on the earth. The cool thing about this hack is that it relies solely on understanding the mechanics of timezones and daylight saving, so itl will work just as well in Javascript as it does in AS2 or AS3.
If you follow the code above you'll see the first thing we do is split out TZD and DST. Once you have these values you can make some estimates about latitude and longitude.
TZD ≈ Longitude
The earth rotates once on it's axis each day so that's 360° in 24 hours, or 15° of longitude every hour. So if we know a user's TZD we can estimate their longitude (east/west) to within about 15°. In reality timezone boundaries are a little wobbly so I'd gave or take another 15°.
DST ≈ Latitude
Using DST to estimate latitude is really inaccurate but if you need to know then this way is better than nothing - here's the theory anyway. As a general rule Daylight Saving Time is adopted by countries with temperate climates. Employing it nearer the poles is pointless and the last thing you need at the equator is more sunshine. In the code above we created a summer and a winter date. By comparing these we can tell if the user's current location employs DST and if it is currently in effect.
There are plenty of special cases for DST (don't get me started on that) but if no DST offset exists in summer or winter then the user is probably within the equatorial band. If DST exists but is not in effect then that hemisphere is in winter, and the opposite hemisphere is in summer. A quick check against the current date will tell you which hemisphere that temporal band is in.
Caveat Emptor
So there you go, GeoLocation using just the Date class. I'm the first to admit that determining latitude is really inaccurate so if you need to know for sure then use server side IP Location. If accuracy is less important then this method is small, self contained and works in AS3, AS2 and Javascript. One last piece of trivia before I finish up; although I said employing Daylight Saving Time near the poles is largely pointless, it turns out that for reasons of synchronicity most Antarctic survey stations follow the DST rules for their home country.
Posted on April 21, 02009
Filed Under Inspiration, Journal, Timelines | Leave a Comment
image courtesy of Google Labs
Temporal search took a big step forward yesterday with the announcement from Andy Hertzfeld of the launch of News Timeline on Google Labs. This is exactly the kind of thing I'm trying to build in Flash so it's exciting to see Google's take on it.
The interface is built in javascript and HTML and is similar to the sideways scrolling Simile Timeline used in other Google projects. Temporally related search results are displayed in columns within a zoomable, graphical timeline.
Historical data can be displayed for dates as far back as the 1400's and from what I can tell they are using the proleptic Gregorian calendar for any dates prior to the Gregorian reform in 1582. Most of the early content is pulled from Wikipedia but dates closer to the present return much richer data. The temporal granularity can be set to day, week, month, year or decade.
Posted on February 25, 02009
Filed Under DaVinci, Development, Flash, Herodotus, Inspiration, Journal, Latham, Projects, Timelines | Leave a Comment

When I came up with the fanciful notion of an interactive timeline that stretches back as far as the Big Bang I thought I was onto something exciting and new. The problem with new ideas these days though, is that you're only one quick web search away from the realisation that they are anything but.
Although I think the interactive visualisation aspect is still new, it turns out that the unified (multi-disciplinary) approach to history has been around for about 25 years. The study of Big History attempts to combine the timescales of cosmology, geology, paleontology, archeology and history into a single unified timeline. As we have more detailed information about events closer to the present, the result is a naturally logarithmic timeline.
Big History courses have been taught in Australia and the US and David Christian's excellent lecture series is available from the Learning Company. The information and insights contained in these books are going to be invaluable for structuring periodization for Herodotus.
Posted on January 30, 02009
Filed Under Inspiration, Journal, Timelines | Leave a Comment
Nick Rabinowitz, a Grad student at UC Berkeley School of Information, posted an interesting announcement on the Google Geo Developer blog this morning. Google TimeMap is a Javascript API for working with geo-temporal data. It combines Google Maps with the excellent SIMILE Timeline and wraps them into a single API. The library supports both JSON and KML data.
The example above shows the lifespans and geographical locations of major figures of the Renaissance. Click through the image to see it in action.
keep looking »