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

jskml: Javascript KML Dialect

KML data structures need to be represented in other formats than just XML. With virtual globes moving into the web browser, the need for an alternate representation that does not require parsing to go from XML text into Javascript objects is an important step, in my opinion, in simplifying web based scripting of online mapping.

I have created a simple static website describing the new dialect at:
http://www.jskml.org.

I used Google App Engine and the Django framework to create this site. I've got another exciting app or two planned for deployment using this platform and this website was a good way for me to orient myself as well as put out a format that I feel should be supported.

KML, libkml and the "standard" mistake

Passing off KML to the OGC so it could become a "standard" was a big mistake for Google.

I consider myself well versed in the KML format since I just implemented most of it's features, and found them to be needing much more in the way of styling. KML will now change at a glacial rate due to the standards process, right when it needs to change the most! Google Earth's feature set will now become dictated by an outside entity, with their input of course, but that's no way to develop software! Why would they cripple Google Earth like that?

Also libkml has been released and it was exactly what I thought it would be, a glorified xml validation script for the kml dialect. I predict that no significant software will choose to link that library in.

I have to say the lamest thing about KML is the whole Style/StyleMap tag collection that enables one to set a separate style on an icon for mouse-over events. It's a great way to have a non-standardized interface since everyone rolls their own mouse-over effect for each placemark style!

I've implemented a few of my own extensions to the KML format which I will go into detail about later. They are mostly aimed at visibility and styling extensions. One of the most useful extensions is the tag which allows one to control the visibility of a Feature element (Placemark or GroundOverlay) globally based on camera elevation. This is much easier than setting up one of those elements, especially for a single placemark.