Thursday, June 19, 2008

KML Extension, Julian Time

Creating a virtual globe that can view KML files as well as creating numerous datasets that have to use KML has given me what I feel is a unique perspective on the strengths and weaknesses of the language. It also gives me a really unique opportunity to enact some features in the language that I feel are needed. Hopefully at some point the OGC and Google will consider some of my suggestions once they are more formalized.

I've just come up with a *really* nice extension to KML that can drastically reduce the size of some datasets (e.g.: a 1.2 MB dataset is reduced to 60K) and at the same time enable functionality that is sorely missing. I'm not going to spill the beans on it quite yet since I've got another couple of enhancements that will enable even more great functionality. I'll present this extension and others when I give my talk at Google on the 15th of July. I'll post a video of that talk on this blog once its available.

Julian Time:
One of the less fortunate aspects of KML, in my opinion, is it's use of the ISO 8601 Date and Time Format. I understand why they did it; because it is human readable and a standard to hang their hat on. The processing overhead on parsing the date is significant, but not a deal breaker so why do I care?

Clearly the ISO time format should be left in, but there should be another option for specifying it as Julian Time. There are so many nice properties of julian time that I would be very surprised if Google Earth, Virtual Earth, ESRI and any other virtual globes don't all use it for their internal representation of time. It is a floating point number (usually a 64 bit double) that can be manipulated with standard mathematical functions. Anyone who has ever written a date library the naive way (as I have) has come to dislike all of the little details like days in a month, leap years and worst of all... time zones. Why not standardize on a time format that does away with all of that dreck and can be operated on like a regular number? You can add 3.5 days, subtract an hour and do simple comparison operations like greater than, less than and equal. I can't imagine ever using another internal representation.

Here's a conversion routine in Python:

# gdate is (year, month [1-12], day, hour, minute, second)
def julian_date(gdate):
if gdate[1] < 3:
M = gdate[1] + 12
Y = gdate[0] - 1
else:
M = gdate[1]
Y = gdate[0]
D = gdate[2] + (gdate[3] / 24.0) + (gdate[4] / 1440.0) + (gdate[5] / 86400.0)
A = math.floor(Y/100.0)
RV = math.floor(365.25*(Y+4716.0)) + math.floor(30.6001*(M+1.0))
return RV + D + (2.0-A+math.floor(A/4.0)) - 1524.5

2 comments:

Al. said...

The problem with this suggestion is that it opens up a can of worms astronomers have been wrestling with for years. There are lots of different types of time. Essentially you're demanding that clients that can parse KML can then transform between all of these different types of time.

With the arrival of Google Sky this would be a useful addition, I'd suggest at least Julian Date (JD), Modified Julian Date (MJD), Heliocentric Julian Date (HJD) and Barycentric Dynamical Time (TDB) should be supported. I'm sure others would call for ET, TDC, TAI, sidereal time and (many) more. Astronomers can get quite argumentative about time standards...

So instead of,

<TimeStamp>
   <when>2007-01-14T21:05:20+0000</when>
</TimeStamp>

we could have

<TimeStamp standard="ISO8601">
   <when>2007-01-14T21:05:20+0000</when>
</TimeStamp>

or

<TimeStamp standard="JD">
   <when>...</when>
</TimeStamp>

or

<TimeStamp standard="TDB">
   <when>...</when>
</TimeStamp>

However the translation from some of the standards need to take into account position (on the sky and on the Earth) and in some cases look-up tables of leap seconds. That can get complicated.

So while I agree that in the best of worlds the standard should support JD and the rest. In practice perhaps its better to put the burden on the person writing the KML, rather than all the client authors, to be able to parse (and then convert to local time) whatever time standard the original time is in, into something that everyone can understand.

Thomas pedro said...

The Realtor you are working with may have their top choice, or in-house advance officers they work with. However in any case, they have to give you no less than a few choices with the goal that you can discover what is accessible. payday loans