[vespa.activity] Solar System resources in the VO

Baptiste Cecconi baptiste.cecconi at obspm.fr
Wed Feb 13 12:19:42 CET 2019


Hi Pierre, 

thanks for pointing this out. This is a topic we have been thinking of in VESPA, without a definitive solution yet, but we have ideas.
 
> Le 12 févr. 2019 à 12:12, Pierre Fernique <Pierre.Fernique at astro.unistra.fr> a écrit :
> 
> 
> Dear Ssig, Apps and VESPA members
> As you probably saw, we have more and more Solar System resources available in the VO.
> This is a really good news (notably hanks to Europlanet effort)
> But for client point of view, and notably Aladin, it is more and more difficult to display and use correctly these new resources as there is presently no standard way to specify the celestial body concerned by each of these resources. Actually, in Aladin, we are face to two issues :
> 
> How to build correctly the data discovery tree ? Concretely, how to move the good TAP, CS and other services to the Solar System branch ?
One option would to have a dedicated mandatory <SUBJECT> item value in the registry record, e.g., "solar system". 
> How to handle the incompatible projections (sky resources over planets, or the opposite, or Mars data over Io, etc...) ?
Here, we would need to provide the target body name also in the registry record. This could be done through the <subject>, naming the target body here, as well as the target region. For instance:

<content>
	<subject>Solar Sytem</subject>
	<subject>Mars</subject>
	<subject>Planetary Surface</subject>
…
</content>
> 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 also had to manually add 3 others resources ( jacobsuni/tap, pvol/tap and  vo-plasma.oeaw.ac.at/tap). The result is not bad (see below) but this method is clearly debatable. And there is no distinction between planets.
> 
I don't think this should be the way to do it, as this relies on the specific implementation of TAP and EPNcore in DaCHS. For instance, the Vizier EPNcore table would not be identified with your hack.
 
Identifying the EPNcore table should rely on the utype of the epncore table, which must be "ivo://vopdc.obspm/std/epncore#schema-2.0". This requires VODataService 1.1. At the moment, this is the assumption of the VESPA client. 
> 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 ? 
> For the VO registry, do we have to invent a dedicated field such as <obsbody>mars</obsbody> ?
Does the content/subject proposal fits this need ? 
> For TAP tables, how to specify that this table concerns this body, or the sky ?
I think this is a bit more tricky than this, as a table may include data records concerning several planets of solar system bodies. 
> 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 ?
In the VO, not really (in STC, there is a list, but not complete). The reference should be the list maintained by the IAU list.

> Reactions ? Suggestions ? Do we have time to discuss this point during Paris Interop ?
> 

I think this is a very nice topic for Paris: it's overlapping with SSIG, Apps, DM, Registry and Semantics.

Cheers
Baptiste
> Cheers
> Pierre Fernique
> 
> <cgpjigkioblcbnll.png>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20190213/0aadd2b7/attachment.html>


More information about the apps mailing list