This is the Earth I was looking for... Español | Deutsch | Français | Italiano | Português

Well I wasn't waiting all that long as today Google released Google Earth for the iPhone.


Sure enough there is geo-location support and the controls are fairly intuitive, including the use of the accelerometer to control your viewing angle which is a fairly neat trick.

Disappointingly, at least from my point of view, there isn't any support for Google Sky. Or at least there isn't any support yet, I'm still hopeful. Time to start lobbying the people I know in Google. I guess the Google Sky and MS WWT tutorial at ADASS will be a good place to start. I'm already talking there anyway.

To get Google Earth on your iPhone, visit the App Store in iTunes...

This is not the Earth you are looking for... Español | Deutsch | Français | Italiano | Português

After spending more time than I should hacking Sky support into Maps.app on my iPod touch I'm somewhat ambivalent about the arrival of Earthscape on the App Store (via the Google Earth Blog).


This is not the Earth I was looking for...

Earthscape has poor imagery outside of the continental United States, and the current version has no KML or accelerometer support and no search capability. Right now at least it's a cool toy. I've bought a copy because I quite like cool toys and I'm sure a bunch of other people will buy it for the same reason, and as a technical demonstrator it's impressive. But as a useful tool? Not at the moment.

At which point I guess I'm still waiting for Google Earth, and Google Sky, for my iPod touch. Of course I can't yet get Google Earth in a browser on my Mac, so I might be waiting a while...

Google Earth in a Browser Español | Deutsch | Français | Italiano | Português

Google Earth, meet the browser...


Unfortunately, for now at least, the browser plug-in is Windows only. While I've been promised that Mac OSX and Linux versions are coming soon, I'm really hoping that OSX support isn't limited to Firefox. For once, I'd like to see a Safari support out of the gate.

Update: Brady Forrest has a good overview over on the O'Reilly Radar, while Dann Catt is poking around the internals over on Geobloggers.

Automating Google Earth (and Sky) Español | Deutsch | Français | Italiano | Português

You know how it is, you're talking to someone over coffee about how things are possible, and the next day you're expected to know intimate technical details about exactly how to do it, and to get it done by close of business that day.

This happened to me at the tail end of last week and as a result I've been taking my first serious look at Applescript and Apple's Automator.

One of the things I needed to do was script Google Earth, and being an astronomer, what I really needed to do was be able to flip between Google Earth and Google Sky automatically. Unfortunately there wasn't anything in the Google Earth Action Pack that allowed me to do this, and Google Earth has a fairly thin Applescript dictionary.

Of course with the release of Mac OS X Panther, Apple introduced features into the System Events process which allows AppleScript to perform some actions in applications that have no, or only partial, built-in scripting support.



So I wrote some Applescripts to drive the Google Earth GUI, and allow me to flip between Earth and Sky modes, but people locally found the idea of Applescript to be a bit scary. So I went ahead and turned these scripts into Automator actions.

You'll notice that these actions use an Applescript delay to wait for image streaming from the server to complete, rather than the built in GetStreamingProgress function. Unfortunately I've not found this function to be terribly reliable, about one time in five it'll get stuck and never report that streaming has completed. This isn't terribly helpful if you need reliable scripts, so I've gone with a delay.

You can download the two automator actions I wrote to switch Google Earth between Earth and Sky modes. If you place these into either /Library/Automator/ or ~/Library/Automator they will show up automatically next time you run Automator, associated with Google Earth. Remember that because these actions reply on System Events you'll need to enable enable UI scripting in the System Preferences before they'll work for you.

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

My quick hack yesterday where I PLASTIC enabled Google Sky generated a lot of email and encouragement. It also got me thinking about where to go next. However today's adventure in Tupperware I lay entirely at John Taylor's feet, it was his idea, although I must admit I hit myself squarely on the forehead and said "Doh!" when he suggested it...


More Google Sky tupperware...
Unfortunately yesterday's code only allowed Google Sky to listen for incoming ivo://votech.org/sky/pointAtCoords messages. Which isn't really as much fun as sending messages back out. I couldn't see an easy way to do that, but John could,

As for sending points out of Google Sky... you could add a URL to a marker so that when the user clicks on it in Google Sky it opens a web page. In our case we could have it pointing at a local web server that converts it into a PLASTIC message. - John Taylor

Of course that'd work just fine, so I quickly modified yesterday's code to do just that. Now when you send a PLASTIC message into Google Sky the <Description> tag in the Placemark has a link which, when clicked, will call back to the facade application's embedded webserver and allow you to send a PLASTIC message back to the Hub. This means we now have bi-directional control, both in and out, of Google Sky with PLASTIC.

I've uploaded the source code again, but please don't look at it too carefully, it's getting to be quite embarrassing how poorly it's written. I don't normally break object encapsulation like I've done here, but I was really keen to get this working. I've been putting off writing a "proper" Perl PLASTIC module for a while now, looks like Google Sky might be the thing that finally makes me do it...

Anyway, enough for today. Time to sit down and down this properly now I've proved to myself it's possible.

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...

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

We knew it was coming for a a couple of years now, and here it is at last. The latest version of Google Earth has the first release of Google Sky embedded inside it. Even if it is quite hard to find...


Google Sky is part of Google Earth v4.2 beta
More from me when I get my head around what it's going to mean for the professional community, but I can see changes coming. I think my VOEvent time line representations might just suddenly have become very old hat. At the very least I think I'd better start generating KML links from inside eSTAR.

Update: I've spent the afternoon poking around with the internals of the VOEvent broker and the KML documentation and I currently have a live network link (KML) connected to the broker. This means that any OGLE, Robonet-1.0, ESSENCE, SDSS, GCN or other event messages that flow across the backbone will be automatically published to Google Sky.

Right now the descriptions and other details attached to the placemarks are fairly basic, but I'll work on this again tomorrow and hopefully make some progress. The other things to take note of here is that this is a live feed, that means there won't be that much to see yet since I haven't pre-populated the network link with content. You'll see it in real time as it flows across the network...

Update: The Caltech guys have had a little bit of a head start since I'm told that Google Sky uses Caltech DPOSS images. This is what they had lined up and ready to roll for the launch,

Today Google has released a new Sky layer for Google Earth. In conjunction, the VOEventNet project is pleased to announce a set of mashups showing recent astronomical transients, updated every 15 minutes. The mashups show GCN feeds (SWIFT, Milagro, Integral), the GRBlog (contains sky-located GCN circulars), as well as OGLE microlensing events. The event feeds contain VOEvents, and drilldown is available to finding charts, light curves, and original VOEvents. - Roy Williams, Caltech

As you can tell from the boilerplate in the credits in their mashups, my own eSTAR project in Exeter is part of the VOEventNet project. In fact we provide the OGLE event feed data they're using in their as OGLE network link. Of course since Google Sky was covered by non-disclosure agreements today is the first I'd heard about things. Oh well...

Update: While those of us on the inside haven't quite grasped exactly what Google Sky means yet, most of us have figured out that the world has changed. There has been a large number of emails flying back and forth on mailing lists today, and I think a few people are going to be surprised by the next few months. But unlike the professional GIS community, who were really surprised by the traction that Google Earth managed to gain amongst professionals and non-professionals alike, astronomers have a long history of the general public looking over our shoulders as we work. So one thing that isn't going to surprise us is user generated content.

Of course we're in the middle of revolution in astronomy with the virtual observatory finally beginning to bear its first fruit. The arrival of Google Sky isn't really a coincidence, but it is well timed. The mashup I put together this afternoon was really only possible because of that timing, two or three years ago the data wouldn't have been accessible in the same way as it is today.

Update: I'm really puzzled by why people are talking about Google Sky as if it was planetarium software. I think they're missing the point, I don't think the guys at Google ever intended it to be planetarium software. Google Sky isn't about whether you can observe the Ring Nebula from where ever you happen to be standing at the time. It's all about publishing, indexing, and sharing information. Surely that was obvious? It's about collaboration and user driven content, surely?

Update: Another quick hack from me to PLASTIC-enable Google Sky.

Google streetside view from Where 2.0 Español | Deutsch | Français | Italiano | Português

News from the O'Reilly Where 2.0 conference of the upcoming release of the much predicted Google street side view (via O'Reilly Radar).


The new Google street side view layer in Google Maps
Of course this isn't new, after all Amazon A9 did this back in 2005, but neither was online mapping applications when Google Maps launched. The question isn't whether they're were first, it's whether their interface is so much better than what's gone before (yet again) that they corner the market. That, and from the sounds of things, whether this gets integrated into Google Earth.

However while the guys over at O'Reilly seem to be able to see this on the Google Maps pages right now, it looks like the rest of us will have to wait for the official announcement during Where 2.0 later today. I certainly can't see the new features and from the comments on their post it doesn't look like I'm alone on that one.

Update: I can confirm that adding &gl=us (via Lifehacker) to the URL does indeed allow you to use the new features, at least from the UK, and from what I remember it blows the interface for the long defunct A9 service out of the water. The way you can click and drag around your location is actually pretty slick.

Update: The guys over at the Google Lat Long blog have pointed us to a video showing how to use the new features.

Automating Google Earth Español | Deutsch | Français | Italiano | Português

A couple of months ago Craig Stanton discovered that Google Earth now had acquired Applescript support.

Applescript is amazingly useful, but scripting applications using it still requires some basic programming knowledge. Which is probably why Apple introduced Automator with the release of Tiger, which allows you to script your applications simply by dragging and dropping predefined actions into a workflow, no coding required.

CREDIT: Automator.us

Building a Google Earth workflow
So the next step is obviously to put together some automator actions for Google Earth, and that's now been done with two such actions; Go To Location and Save Screenshot, having been built around the Google Earth Applescript library and released as the Google Earth Action Pack (GEAP) on Automator.us.


Google Earth for Mac with Automator actions
As Ogle Earth points out this is perfect for building scripted tours with voice overs, although with the limitation that Automator has no easy way of playing prerecorded sound files, so at least for the moment you have to use a synthesised voice.

Google Earth and Applescript Español | Deutsch | Français | Italiano | Português

Update: Google Earth and Automator actions
Craig Stanton has discovered that Google Earth now has basic AppleScript support, and has put together a Geotagger droplet as a proof of concept demonstration.


The supported Applescript commands
Stefan Geens over at Ogle Earth was fairly excited about this discovery and immediately pushed the boundaries by using the AppleScript support and Jonas Salling's Salling Clicker to build himself a Bluetooth remote control for Google Earth.


Google Earth by remote control...
You have to love this stuff, great work guys...