[ssig] Solar System resources in the VO

[Stéphane Erard]

Dear all

I’ve received this mail via 2 different threads, so I’ll comment separately
First, thanks to Pierre and the Aladin team for their progress on the matter, we’re immensely happy on VESPA side to see our data services accessed by such powerful tools.

> Le 12 févr. 2019 à 13:02, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> 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.  

This is certainly the right way to proceed, but some of the DaCHS servers used for EPN-TAP are no up-to-date, and some services did use an alternative EPN-TAP mixin. This is probably the origin of the problem. 
Looking at Aladin beta, I see 39 tables - we actually have 44 published, and the set of 39 in Aladin is not consistent - there are duplications, and also test services which should not be published / accessible. We certainly have to clean up a little on our side (i.e., purging these test services and upgrading the other servers).

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

As Françoise pointed out, the IMCCE Quareo resolver provide a list of Solar System bodies (several lists from various sources in fact, including IAU's). This is used routinely by the VESPA portal with no problem.
The association is up to the service providers, they know the purpose of their data. 

We’ve also been working on a list of Solar System reference frames  in VESPA, with USGS and the PDS/PPI node.

Stéphane

> 
>      -- Markus
> _______________________________________________
> ssig mailing list
> ssig at ivoa.net
> http://mail.ivoa.net/mailman/listinfo/ssig