KML (was Re: call for presentations at the Data Model sessions in Cambridge , September 2007)

[Alasdair Allan]

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.

Obviously...

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

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

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

I'd argue that point, but I guess it depends what you're trying to  
visualise.

> JPEG's are a wide reach vehicle, but should we transfer all  
> astronomy images from FITS to JPEG because it's adoption is so  
> widespread?

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

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

Al.