[ssig] Solar System resources in the VO

[Francoise Genova]

Hi all,

I agree with Pierre that knowing which body a resource deals with is 
important for searching relevant data (ie from the end user point of 
view), and it will be more and more needed while the number of solar 
system reources will grow up. As Markus says, it is not straightforward 
in all cases but to my knowledge IMCCE has a reference list for names of 
the solar system bodies a la SIMBAD which could be used as a starting 
point. The more complex cases should be discussed in the Semantics WG. 
For me Earth includes the Earth magnetosphere as a first approximation - 
and I used to study planetary magnetospheres long ago. VESPA may already 
have dealt with these questions in their portal.

Best

Francoise

Le 12/02/2019 à 13:02, Markus Demleitner a écrit :
> 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