Solar System resources in the VO

[Markus Demleitner]

Hi Pierre,

On Tue, Feb 12, 2019 at 12:37:54PM +0100, Pierre Fernique wrote:
> 1. How to build correctly the data discovery tree ? Concretely, how to
>    move the good TAP, CS and other services to the Solar System branch ?
> 2. How to handle the incompatible projections (sky resources over
>    planets, or the opposite, or Mars data over Io, etc...) ?
> 
> I progressed a little. For the first point, I made a very bad hack based on
> the ivoid. We're lucky, most solar system resources use EPN-core + DACHS
> server... and DACHS automatically uses an ivoid containing the substring
> "/epn". By magic, 35 resources are now placed in the Solar System branch. I

The thing I've been advocating here (and I *hope* it's the official
version by now): epn-tap tables must have

ivo://vopdc.obspm/std/epncore#schema-2.0

in their tableset//table/@utype attribute.  It turns out that some
services still use "epn-tap 2.0" here.  I'm not sure why this is and
believe it's not my fault; I'll follow up on this.  Anyway, using
this, discover EPN-TAP tables like this:

select * from rr.res_table 
where table_utype in ('ivo://vopdc.obspm/std/epncore#schema-2.0', 'epn-tap 2.0')

(use the normal joins to get to the associated TAP capabilities, but
you'll need the table names from here).

> For the second point, I have not found a solution. Only Solar System HiPS
> maps have a dedicated keyword for each body. But  as it is not the case for
> other resources of the Solar System, I can not presently use this keyword.
> 
> *So the question : How to characterize Solar System resources in the VO ? *
> 
> 1. For the VO registry, do we have to invent a dedicated field such as
>    <obsbody>mars</obsbody> ?

Frankly, I'd rather avoid this; where do you start, where do you
stop, who's going to maintain the list of objects, and where are
their boundaries (think "Earth" vs. "Earth magnetosphere"?

For now, I think it would already be great if the SSIG could come up
with a list of reference frames for expressing the coverage as per
our STC roadmap: http://ivoa.net/documents/Notes/Regstc/index.html.
Just having a look at what data is there and making terms for
anything occurring more than once (perhaps including a bit of
expectation) should, I think, work fine.

That would solve the problem of enabling spatial searches on such
resources, and perhaps it'd already be good for grouping (after all,
resources using the same reference frame are eligible for
overplotting).  I'll not deny that this list would come handy for my
VODataService 1.2 activities, too.

> 2. For TAP tables, how to specify that this table concerns this body,
>    or the sky ?

If reference frame names are good enough, the coverage element plus
potentially auxiliary resources would do this trick.  Of course,
once a resource contains things from multiple celestial bodies or in
special frames there's nothing we can do right now.  I suppose
there's always going to be a need for an "other" branch.

> 3. How to handle the list of celestial bodies ? Do we have to provide a
>    list (mercury, venus, earth, moon, mars, io,...) somewhere in the VO ?

I'd recommend using a vocabulary; I promise there's even going to be
a proper process for maintaining them real soon now.  But the first
step certainly is to draw up what reference frames we initially want,
and then, based on this, whether that list is good enough to cover
the additional discovery/resource tree use case.

      -- Markus