Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Roadmap described here: Planetary Science requirements in the VO



2022

Actionfromtopurposestatus / answer

Units / spectro

Surface brightness in Jy / arcsec^2 (for observational purpose, not lab) — ? To be supported in CASSIS and converted to W / m2 / µm







2020

Actionfromtopurposestatus / answer

Datalink usage?

  • Question arises from duplicate granules providing alternative formats in EPN-TAP services. EPN-TAP v2 requires one granule / format in use (e.g. OMEGA_cubes service with both IDL and netcdf formats). Associated granules share the same obs_id (and other parameters) and have different access_format, so that different formats can be sorted out by a TAP query. This is nonetheless considered an issue for Aladin, and datalink is suggested to solve this.
  • However, grabbing a given entry in a datalink table associated to a granule is not easy in general. An alternative format may be provided through, e.g.:
    semantics="#auxiliary",
    contentType="application/x-votable+xml"
    The point is: how do a portal or tool will grab files from this table for 20 selected granules?
  • First, there does not seem to be an automated procedure to retrieve a bunch of files from a datalink table in TOCAT or Aladin at the moment (TBC).
  • The current semantic vocabulary is too limited to identify an alternative format. This may improve in the short term with the addition of "alternate", "sibling" or whatever new name (but remember than other types of files can be listed in this datalink table, such as raw data files…)
  • However, access would still require to pick-up a given mime-type from this table. 

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

Actionfromtopurposestatus / answer

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

IVOA semantics
(sent Oct 2019)


• Add date of query in return VOtable from Dachs (or ask how to add it)SEMarkusQueried to ~identify version of evolving services
• In HiPS metadata: hips_frame should accommodate planetary coordinate systems (when ready) in addition to celestial onesSEPierre FerniqueIdentify body and reference  frame
• Clarify conditions to reuse HiPS in external sotware (issue with CNES and possibly other environments)SEPierre Fernique



2019

Actionfromtopurposestatus / answer

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



Not needed

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)

SEIVOA semanticsAlso required to introduce projection parameters using various standards (Proj4…)
• UCD needed for VOeventsSEIVOA semantics

• Clarify usage of inf / -inf / Nan in ADQL (should apparently exist, as per DALI - but do not)SEIVOA semantics / vocabularies

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

SEIVOA 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)
definition: Ratio of radiance to incident normal solar flux

SEIVOA semantics

• 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

SEIVOA semantics

How do we handle hemispherically integrated quantities?SEIVOA semanticsreflectance / 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?

SEIVOA semantics

On the same token, 

phys.angVeloc would look more consistent than phys.veloc.ang

SEIVOA semantics

Additional set of UCDs for spectroscopy. In particular, a category phys.scattering seems required, see here

+ arithm.ang could do for angular distributions

SEIVOA 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)
SEIVOA semanticsAt 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? SEMark TaylorThis 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

Actionfromtopurposestatus

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!


Simulations may currently include the prefix ;meta.modelled after measurement_type (not always implemented, though). We're asking a more comprehensive system to IVOA, to also support experimental data - but this has to be agreed upon.

Review board


SE



Use ;meta.modelled  in EPN-TAP services when required


Interop May 2017 (Shanghai)

...