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. Received on 2008-01-22Z21:49:41