...
Roadmap described here: Planetary Science requirements in the VO
Interop May 2017 (Shanghai)
All this to be discussed in advance on mailing lists.
2020
Action | from | to | purpose | status |
---|
Ask to include VESPA related tools in IVOA Application lists:
- VESPA : http://vespa.obspm.fr
web application, EPN-TAP (and PDAP) client / Query databases
connected to VO tools via SAMP
- APERICubes: http://voparis-apericubes.obspm.fr
web-based tool
Spectral cube slicer for PDS3 formatted cubes (VIRTIS on Venus-Express and Rosetta, currently) and GIRAFFE fits.
Connected via SAMP, both in I/O
- 3Dview, CASSIS and AMDA have been upgraded to include an EPN-TAP specific client
(3D view is not yet included in page http://www.ivoa.net/astronomers/applications.html)
developments
Included
requested 4/2020
Applications
- Evolution of SAMP messages (content) we want to add:
- geojson
- pds3 + pds4 (+ datalink ?)
- Add geojson output to DACHS (for s_region)
Mark Taylor and Thomas Bochs
Markus
2019: DaCHS geojson output to be fixed. Requires definition of std coord frame IDs for solid bodies…
UCDs and Utypes for Solar System
- See list in EPN-TAP V2.0 parameters (related to parameters)
UCDs in red and italics/blue are non standard but needed by VESPA.
- Measured levels in spectroscopy:
see Spectral quantities in use for Planetary Science
- Add "spectral matrix" UCD (use case = want to know that data can be sent to iPECMan): phys.spectralmatrix
- UCD for gravitational field "Power Spectrum of Spherical Harmonic Coefficients of Lunar Gravity Model": phys.gravitation
- Shape model (full 3D shape) or Terrain Model (or Elevation model) with respect to geoid or ellipsoid: phys.shape, phys.shape.elevation (SE: the last one is ambiguous; elevation usually refers to altitude above a datum, not to a digital terrain model - phys.shape.dtm could do)
Spectroscopy
- How do we pass Utypes and UCDs to VO tools? Really included in VOTables only, not in fits ?
The reason is apparently related to the length of value fields in fits. - Add fits kw for UCD (and Utypes, if space permits)?
Otherwise, data handling in tools depends on how data are transmitted.
this is addressed in SDM2, TBC
ADQL additions
- we need to look inside a field of list, ie to combine ivo_hashlist_has with LIKE
e.g. to look for a UCD in a list (and get time vs time;stat.min)
measurement_type
in particular, but also
instrument names, etc
- Use case for "ivo_hashlist_has" : function to parse list in ADQL. We need an ADQL function to handle a multi valued field. Idea from markus is that we should not asked ADQL transformation but put that in endorsed note. He will help in writing it, but doesnt want to be the handler of it in IVOA. What we have to say, is that we have use case for it target_name, target_class. That also exist in obscore. Moreover this function is used in relational registry interogation and will be handle by Gregory library and DaCHS. We could handle this note if TCG thinks it's the right way to go.
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:
- Spectral aggregates? Required to plot measurements from spectrometers with several channels
(very common in our field).
Appears to require a formatting standard to store several spectral elements in the same file - Computing functions / statistics - I want to get the average of several profiles/spectra sent from a service. Is this SODA-related? Is this a function on the data server? I'm thinking more about a function to call with a selection of data already retrieved on user side.
SE
SE
J-M Glorian?
OK with dedicated script in CASSIS, to be made more generic
- TOPCAT:
-Implement cross-matches based on s_region (in addition to cone search-like criteria)?
-Better support of Healpix maps
- cross-match of footprints supported via TAP, fixed in DaCHS (early 2019)
- Healpix maps now consistent with Aladin equivalent (early 2019)
- Aladin (to be discussed directly with P Fernique?):
See fits format items- stability issue of v9 on Mac / java 1.8 (blocks on my machine at startup very often) - seems OK in v10beta
- issue with auto hips from files on v9: does not work as expected, and never finishes on my side (TBC with more recent versions)
- implement E-handed frames in s_region (see STC item)
Pierre Fernique
Fits format:
- Chiara's request for additional keywords to support projections on planetary surfaces
- Need to implement the planetary ref systems in Aladin, they are part of the fits std:
MALN + MALT, etc + proj types (see her ex Mars & Venus) - Define equivalent for Earth (don't seem to exist)
- Current fits keywords do not allow for image projections on ellipsoids, even less on a 67P
(one kw missing, see Chiara's docs)
STC, etc:
- s_region is very nice, but we need a E-handed system with longitudes [0, 360[ to respect IAU conventions.
Additional predefined system required:
We're currently using UnknownFrame, which appears to be W-handed (it is used like this in Aladin at least). We need something similar but explicitly E-handed. Call it BODY, or BODY-FIXED, or E-HANDED?
Or combine UnknownFrame with another property?
frames, consistency with
IAU conventions
- AstroCoords for VOEvent: we need to be able to tell that the event occurs at a named planet or a spacecraft (e.g., "Jupiter", "Juno") in the WHERE section.
TCG discussion
- function to parse list in ADQL : We need an ADQL function to handle a multi value field that is resume in a single field. Idea from markus is that we should not asked ADQL transformation but put that in endorse note. He will help in writing it, but doesn't want to be the handler of it in IVOA. What we have to say, is that we have use case for it target_name, target_class. That also exist in obscore. Moreover this function is used in relational registry interrogation and will be handle by Gregory library and DaCHS. We could handle this note if TCG thing it's the right way to go.
There is also another function to handle Hips in ADQL with first implementation in DaCHS, use case are already there, it's not our goal, but we may use it and it's another argument to build this note and circulate it.
This is a question to DAL, but Baptiste must ask in TCG a way to build it as input come from different group (Planetary Science, Registry, Hips ?)
- Endorsement of VOResource schema that is necessary to register EPN-TAP service in RofR registry. That yet stop for non compliance (ivo-id containing # characters should be valid)
- open
- 2nd item fixed in Dec 2017?
VOEvent:
- Using ORCiD for identification of author ?
- See STC comments also
2018
...
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
...
Check here for recent discussions (mostly the first one which addresses these questions):
https://wiki.ivoa.net/twiki/bin/view/IVOA/UCDList_1-4_2017Jun_2018Feb_RFM
https://wiki.ivoa.net/twiki/bin/view/IVOA/RFMforUCD
https://wiki.ivoa.net/twiki/bin/view/IVOA/UCDList_1-3_RFM
...
Coordinates:
• pos.bodyrc needs to be used as primary (relates to body coord system, as pos.lunar)
...
SE
...
Maps:
• At least a new pos.projection is required to introduce projection/mapping scheme (there is currently only a very specific pos.lambert). Possible values as in fits, extended to support georeferentiation (Marmo et al 2018)
...
• Correct/clarify definition of reflectance in 2018 RFM sheet:
add Q | phys.reflectance | Radiance factor (received radiance divided by input radiance)
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.
...
• 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)
definition: Ratio of radiance to incident normal solar flux
...
• Suggestion for reflectance in 2018 RFM sheet, to be corrected:
for normalized reflectance concept: proposal arith.ratio;phys.reflectance
definition : reflectance normalized per reflectance at one wavelength
=> Should be arith.factor;phys.reflectance
...
"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
...
• All the above UCD comments transmitted to IVOA semantics on 9 Oct 2019
2019, next
...
Check here for recent discussions:
https://wiki.ivoa.net/twiki/bin/view/IVOA/UCDList_1-3_RFM
...
Coordinates -
The above page includes a proposal to add pos.bodycentric & pos.bodygraphic (which are not standard terms) to cover both the planets and the Sun (but not the Earth)
With description:
- Discussion : In body-centric coordinates, longitudes are defined from sub-observer point, while body-graphic coordinates are defined from a standard body reference frame
and a comment:
TODO: VESPA team to check consistency between heliocentric and planetocentric definitions
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.
-graphic= The planetographic latitude of a point on the reference surface is the angle between the equatorial plane and the normal to the reference surface at the point. W longitudes (measured positively to the West) are used when the rotation is direct and E longitudes are used when the rotation is retrograde.
(we may want to simplify this a bit…)
+ notice that this only applies to planets and satellites (not to small bodies, and other conventions are mentioned for the Sun and Earth).
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“).
Instead, these systems are defined in Thompson A&A 2006 - which states that “there is no distinction between planetographic and planetocentric latitudes and longitudes for the Sun“ and recommends to use the standard term “heliographic“ in this context.
So… shouldn’t we keep the widely used and unambiguous pos.planetocentric / pos.planetographic, and add pos.heliographic to these?
Use cases:
- UCD to be associated with coordinates, e.g. in a VOtable, for use in tools.
- Can also be used for c1min, etc with body fixed frames in EPN-TAP: pos.bodyrc.lat;pos.planetocentric (this is the reason to have a global term I guess).
But in both cases our spatial_coordinate_description parameter is more detailed (to be finalized)
...
SE
...
2020
Action | from | to | purpose | status / answer |
---|---|---|---|---|
Datalink usage?
Altogether, the benefit of datalink to access alternative file formats is unclear: this still requires a service-specific tweak and a multiparameter query; plus a (new?) mechanism in tools. | SE, discussion with PFernique / answer | |||
Datalink usage?
Altogether, the benefit of datalink to access alternative file formats is unclear: this still requires a service-specific tweak and a multiparameter query; plus a (new?) mechanism in tools. | SE, discussion with PFernique | |||
2019, next
Action | from | to | purpose | status / answer |
---|---|---|---|---|
Check here for recent discussions: | ||||
Coordinates - With description:
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“). Use cases:
But in both cases our spatial_coordinate_description parameter is more detailed (to be finalized) | SE | IVOA semantics (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 | |
• In HiPS metadata: hips_frame should accommodate planetary coordinate systems (when ready) in addition to celestial ones | SE | Pierre Fernique | Identify body and reference frame | |
• Clarify conditions to reuse HiPS in external sotware (issue with CNES and possibly other environments) | SE | Pierre Fernique |
2019
Action | from | to | purpose | status / answer |
---|---|---|---|---|
Check here for recent discussions (mostly the first one which addresses these questions): | ||||
Coordinates:
| SE | Not needed | ||
Maps: | 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. | SE | IVOA semantics | ||
• 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) | SE | IVOA semantics | ||
• 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 | SE | IVOA semantics | ||
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: thedirectioninwhichoneobjectliesrelativetoanotheronthecelestialsphere,measuredindegrees fromnorthinaneasterlydirection) | 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? | SE | IVOA semantics | ||
On the same token, phys.angVeloc would look more consistent than phys.veloc.ang | SE | IVOA semantics | ||
Additional set of UCDs for spectroscopy. In particular, a category phys.scattering seems required, see here + arithm.ang could do for angular distributions | SE | IVOA semantics | ||
How do we handle asymmetric error bars? Required by some services | SE | — | use stat.error;stat.min stat.error;stat.max | |
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
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
| Use ;meta.modelled in EPN-TAP services when required |
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) & App chair for this page | Advertise VESPA developments | Included requested 4/2020 |
Applications
| PLS | Mark Taylor and Thomas Bochs Markus | 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. |
| 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 | - cross-match of footprints supported via TAP, fixed in DaCHS (early 2019) - Healpix maps now consistent with Aladin equivalent (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 | 2019: Now included in GDAL fits driver (TBC) |
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 |