Turning Google Sky into Tupperware Español | Deutsch | Français | Italiano | Português

The PLASTIC protocol is one of the big successes to come out of the IVOA and the VOTech Project. It is a simple to use, and perhaps more importantly simple to implement, communication protocol for client-side virtual observatory tools.

PLASTIC is a protocol for communication between client-side astronomy applications. It is very simple for application developers to adopt and is easily extended. Through PLASTIC applications can do tasks such as instruct each other to load VOTables, highlight a subset of rows or load an image of a particular area of sky. Although such operations are quite simple, they enable powerful collaborations between tools. The philosophy is that the astronomer should have a suite of interoperating tools at his disposal, each of which does one thing well and which can be composed according to his particular needs...

So of course one of the first things that occurred to me when I saw Google Sky was whether it could be made to play nice with all the other virtual observatory tools that are now PLASTIC-aware, and in the process turn it into so called "tupperware".


Google Sky as tupperware
It finally occurred to me this afternoon how you could do it, and I'm a bit embarrassed it has taken this long. I've written a small PLASTIC application, a facade, which registers with the PLASTIC Hub as normal and listens for ivo://votech.org/sky/pointAtCoords messages. These are PLASTIC messages telling interested applications to "point at" an RA & Dec. When such a message is passed through the Hub, say by CDS Aladin, it is forwarded to the facade application, which then builds a KML placemark file. The facade application then exposes this KML file via an embedded web server. If you then point Google Sky at this KML file via a new network link set to periodically update, e.g.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.2" hint="target=sky">
<NetworkLink>
 <name>Plastic Application</name>
 <open>1</open>
 <Url>
  <href>http://localhost:8001/getPoints</href>
  <refreshMode>onInterval</refreshMode>
  <refreshInterval>30</refreshInterval>
 </Url>
</NetworkLink>
</kml>

then any RA & Dec points getting passed through the PLASTIC Hub will start to appear as Placemarks inside Google Sky in more or less real-time. In other words, and to cut a long story short, I've sucessfully managed to PLASTIC-enable Google Sky, at least for inbound messages. Which is good enough to be going on with...

I've uploaded the Perl source code to the simple application which I put together to PLASTIC-enable Google Sky. So if you're a heavy PLASTIC user, and plan to become a heavy Google Sky user too, you might want to take a look. If you do want to run it, the pre-requisite Perl modules are below,

Config::User
File::Spec
Carp
Data::Dumper
Net::Domain
POSIX
Errno
XMLRPC::Lite
XMLRPC::Transport::HTTP
HTTP::Daemon
HTTP::Status

and if you don't already have them, they can be found on CPAN.

Of course with John Taylor having just been hired away from the VO by Google there may be a real PLASTIC interface in Google Sky's future, as John is widely considered inside the IVOA to be the man behind the protocol. Although he'll normally point you to the list of other people involved and shrug his shoulders if you mention that. But in the mean while, I'm pretty happy with my quick hack...

Update: More Google Sky Tupperware...