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.
Action | from | to | purpose | status |
---|---|---|---|---|
Ask to include VESPA related tools in IVOA Application lists:
| SE | helpdesk for this page (ivoadoc@ivoa.net) & Pierre Fernique for this page | Advertise VESPA developments | |
Applications
| PLS | Mark Taylor and Thomas Bochs | 2019: DaCHS geojson output to be fixed. Requires 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. |
| BC | |||
Spectroscopy
| SE | this is addressed in SDM2, TBC | ||
ADQL additions
| SE | Support of UCDs in measurement_type 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:
| SE SE | J-M Glorian? | OK with dedicated script in CASSIS, to be made more generic | |
| M. Taylor (passed, TBC for him) | Done (early 2019) | ||
| SE | Pierre Fernique | All those fixed in v10. However open issues are shown on Aladin pages in Confluence | |
Fits format:
| SE / Chiara Marmo | ? - IAU fits commission? | Support planetary mapping & surface feature catalogues | |
STC, etc:
| SE | Markus Demleitner, Dave Morris | Support body fixed frames, consistency with IAU conventions | 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) |
| John Swinbank | |||
TCG discussion
| PLS |
| ||
VOEvent:
| BC | John Swinbank |
2018
Action | from | to | purpose | status |
---|---|---|---|---|
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!
| Review board
|
2019
Action | from | to | purpose | status |
---|---|---|---|---|
Check here for recent discussions (mostly the first one which addresses these questions): | ||||
Coordinates:
| SE | Not needed | ||
Maps: | SE | also required to introduce projection parameters using various standards (Proj4…) | ||
• UCD needed for VOevents | SE | |||
• Clarify usage of inf / -inf / Nan in ADQL (should apparently exist, as per DALI - but do not) | SE | |||
• Correct/clarify definition of reflectance in 2018 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. Can we can keep phys.reflectance for the reflectance factor (standard quantity for lab measurements, currently listed as phys.reflectance.factor) = ratio of radiance to that of a Lambertian disk at the same distance and illuminated under the same incidence (also called radiance coefficient)? - no, this is only a mess… 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. | SE | |||
• 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) | ||||
• Correct suggestion for reflectance in 2018 sheet: for normalized reflectance concept: proposal arith.ratio;phys.reflectance => Should be arith.factor;phys.reflectance | SE | |||
How do we handle hemispherically integrated quantities? | SE | |||
How do we handle asymmetric error bars? Some services need to have stat.error.min/max | SE | use stat.error;stat.min stat.error;stat.max | ||
How do we specify an additive constant / offset? The only close match is arith.zp, which is context specific (for magnitude scales) | SE | At least enlarge the definition to any type of offset / additive constant |