This page lists requests sent / to be sent to IVOA discussion groups to accommodate VESPA needs.
Roadmap described here: Planetary Science requirements in the VO
Interop May 2017 (Shanghai)
All this to be discussed in advance on mailing lists.
Ask to include VESPA related tools in IVOA Application lists:
|SE||helpdesk for this page (firstname.lastname@example.org) & Pierre Fernique for this page||Advertise VESPA |
Mark Taylor and Thomas Bochs
2019: DaCHS geojson output to be fixed. Requires definition of std coord frame IDs for solid bodies…
UCDs and Utypes for Solar System
|SE||Mireille Louys||required to support experimental work, but also observations||Discussed in May 2018 (Victoria interop) for inclusion.|
this is addressed in SDM2, TBC
|SE||Support of UCDs in |
in particular, but also
instrument names, etc
|PLS||François Bonnarel, Dave Morris, Markus Demleitner|
RegTAP functions have been reviewed by TCG, included “ivo_” functions. We can refer to that in EPN-TAP service specification. It is a function to implement on server-side, by data provider. It exist already in DaCHS, it seems to be easy to implement with Gregory Mantelet’s library.
Tools / standards:
OK with dedicated script in CASSIS, to be made more generic
- cross-match of footprints supported via TAP, fixed in DaCHS (early 2019)
- Healpix maps now consistent with Aladin equivalent (early 2019)
|All those fixed in v10. However open issues are shown on Aladin pages in Confluence|
SE / Chiara Marmo
|? - IAU fits commission?||Support planetary mapping & surface feature catalogues||2019: Now included in GDAL fits driver (TBC)|
|SE||Markus Demleitner, Dave Morris||Support body fixed |
frames, consistency with
|new version of TAP (v1.1) removes reference frame in box, circle, polygon. Client must do the query correctly, interpreting the TAP service coordinate frame (default is ICRS)|
It would be very important to be able to specify if one wants to search for model outputs, experimental data or observations. Right now it is not possible to specify it, and if used blindly it can be very confusing!
|Use ;meta.modelled in nEPN-TAP services when required|
|Action||from||to||purpose||status / answer|
Check here for recent discussions (mostly the first one which addresses these questions):
|SE||IVOA semantics||Also required to introduce projection parameters using various standards (Proj4…)|
|• UCD needed for VOevents||SE||IVOA semantics|
|• Clarify usage of inf / -inf / Nan in ADQL (should apparently exist, as per DALI - but do not)||SE||IVOA semantics / vocabularies|
• Correct/clarify definition of reflectance in 2018 RFM sheet:
Radiance factor is the same as I/F; in this case, this is divided by input irradiance (not radiance), i.e. by solar flux.
In any case, this is not necessarily similar to albedo (which is typically integrated spectrally/in angular domain, and is then related to thermal equilibrium). I would keep albedo for more general purpose.
• Correct/clarify brdf in 2018 sheet:
addQ | phys.reflectance.bidirectional.df| Bidirectional reflectance distribution function
The UCD is very weird, would better be phys.reflectance.brdf (this is not a subset of .bidirectional)
• Suggestion for reflectance in 2018 RFM sheet, to be corrected:
for normalized reflectance concept: proposal arith.ratio;phys.reflectance
=> Should be arith.factor;phys.reflectance
|How do we handle hemispherically integrated quantities?||SE||IVOA semantics||reflectance / emission|
|posAng is commonly mistaken for a generic UCD for angles (which does not exist). Make definition more explicit (e.g., Free dictionary: the direction in which one object lies relative to another on the celestial sphere, measured in degrees from north in an easterly direction)||IVOA semantics|
|Section 8, 2 (about pos): |
"the angular size of an object is in this section, its linear size is in the phys section)"
But we have phys.angSize (with an unclear definition) )- should be in pos?
On the same token,
phys.angVeloc would look more consistent than phys.veloc.ang
Additional set of UCDs for spectroscopy. In particular, a category phys.scattering seems required, see here
+ arithm.ang could do for angular distributions
|How do we handle asymmetric error bars? |
Required by some services
|How do we specify an additive constant or offset? |
The only close match is arith.zp, which is context specific (for magnitude scales)
|SE||IVOA semantics||At least enlarge the definition to any type of offset / additive constant|
|Add JSON output to TAP standard?||SE||must be faster than VOtable (critical in the VESPA portal)|
|SAMP only passes the first table resource of a VOtable, seems to be in the standard - although TOPCAT can actually open all tables when provided directly. Why that?||SE||Mark Taylor||This is a problem to send VizieR catalogues from VESPA portal (but also from TAPhandle).||Mark's answer: Done on purpose. |
The solution is to send table resources one by one from the interface / client
• All the above UCD comments transmitted to IVOA semantics on 9 Oct 2019
|Action||from||to||purpose||status / answer|
Check here for recent discussions:
and a comment:
First, the discussion is inadequate and instead relates to rotating frames. This has to be corrected along these lines (from IAU WGCCRE 2015 report):
-centric= a right-hand spherical coordinate system in which latitude is defined as the angle between a vector passing through the origin of the spherical coordinate system and the equator, and longitude is the angle between the vector projected onto the X Y plane and the positive X axis (the projection of the prime meridian on the X Y plan) measured in an eastern direction.
Second, enlarging the concept to the Sun surface is certainly useful, although the term “heliocentric" is not used in WGCCRE reports and traditionally refers to something different (just like “geocentric“).
But in both cases our spatial_coordinate_description parameter is more detailed (to be finalized)
(sent Oct 2019)
|• Add date of query in return VOtable from Dachs (or ask how to add it)||SE||Markus||Queried to ~identify version of evolving services|