KML (was Re: call for presentations at the Data Model sessions in Cambridge , September 2007)
aa at astro.ex.ac.uk
Tue Jan 22 12:49:05 PST 2008
Hmm, this seems to be a continuation of a thread from August before
the Cambridge Interop...?
Jonathan Fay wrote:
> Alasdair Allan Wrote
>> When it comes down to it, I think KML is going to start getting
>> heavily used. I think the IVOA should think seriously about
>> putting it's official blessing on such use, because it's going to
>> happen with or without it...
> We obviously can't ignore the impact of KML, but while it might be
> one a way of interoperating, unless it is fixed it should not be
> the default way.
Well of course it shouldn't be the default way. But as I said
somewhere else in the same thread...
". I wasn't suggesting replacing VOTable with KML, that's
obviously nonsense. I was suggesting adopting KML for KML type
scenarios inside the VO, and not going out and reinventing the wheel.
For instance, for visualisation purposes KML is an excellent
alternative return from something like Cone Search or Simple Time
Access Protocol (STAP) or its eventual replacement Simple Event
Access Protocol (SEAP)."
> We should not give up the top and bottom 20 degrees of the sky.
> In WWT we don't just want to get imagery into the application, but
> the rich metadata so we know as much about that imagery, know how
> to get the FITS data behind it, etc. That is not possible with KML
I'd argue that that isn't necessarily the case, depending on what
meta-data you want to import, and how you want to display that meta-
data. Certainly depending on the data, the way I'd go about
displaying the meta data is to use Plastic to push data out of Google
Sky and into something more appropriate for displaying and
manipulating meta-data. After all that's what Plastic was designed
> It is possible dealing with native VO standards. The missing part
> is the real-time visualization interfaces, and KML does not do a
> good job with that for astronomy data, at least not in its current
I'd argue that point, but I guess it depends what you're trying to
> JPEG's are a wide reach vehicle, but should we transfer all
> astronomy images from FITS to JPEG because it's adoption is so
Well of course not.
> Of course not.
> KML has the same parallel. We should not consider it a substitute
> for standards that preserve the quality of astronomical image and
No, but it is a perfect complimentary standard to those we have
already. It fills a (big) gap in the IVOA portfolio of standards (and
More information about the dal