• im (= image): scalar field with two spatial axes, or association of several such fields, e.g., images with multiple color planes, from multichannel or filter cameras. All vectorial 2D fields are described as catalogue (see below).
  • ma (= map): scalar field / rasters with two spatial axes covering a large area and projected either on the sky or on a planetary body, associated to a Projection parameter (with a short enumerated list of possible values). This is mostly intended to identify complete coverages that can be used as reference basemaps. Does this require a secondary UCD notation (e.g., ;map)?
  • sp (= spectrum): measurements organized primarily along a spectral axis, e.g., a series of radiance spectra. This includes spectral aggregates (series of related spectra with non-connected spectral ranges, e.g., from several channels of the same instrument - TBC).
  • ds (= dynamic_spectrum): consecutive spectral measurements through time, organized primarily as a time series. This typically implies successive spectra of the same target / field of view.
  • sc (= spectral_cube): sets of spectral measurements with 1 or 2D spatial coverage, e.g., imaging spectroscopy. The choice between image and spectral_cube is dictated by the characteristics of the instrument (which dimension is most resolved & which dimensions are acquired simultaneously). The choice between dynamic_spectrum and spectral_cube is related to the uniformity of the field of view.
  • pr (= profile): scalar or vectorial measurements along 1 spatial dimension, e.g., atmospheric profiles, atmospheric paths, sub-surface profiles, traverses…
  • vo (= volume): other measurements with 3 spatial dimensions, e.g., internal or atmospheric structures, including shells/shape models (3D surfaces).
  • mo (= movie): sets of chronological 2D spatial measurements
  • cu (= cube): multidimensional data with 3 or more axes, e.g., all that is not described by other 3D data types such as spectral cube or volume. This is mostly intended to accommodate unusual data with multiple dimensions.
  • ts (= time_series): measurements organized primarily as a function of time (with exception of dynamical spectra and movies, i.e. usually a scalar quantity). Typical examples of time series include space-borne dust detector measurements, daily or seasonal curves measured at a given location (e.g. a lander), and light curves.
  • ca (= catalogue): applies to a single granule providing a list of events, a catalog of object parameters, a list of features... "Spatial vectors" (e.g., vector information from a GIS, spatial footprints…) belong here. This is relevant, e. g., for collections of vectorial elements (e.g. crater lists or ROI definitions) which can be handled directly in a specialized environment such as a GIS. This includes maps of vectors, e.g., wind maps.
  • ci (= catalogue_item): applies when the service itself provides a catalogue, with entries described as individual granules. The service can be, e. g., a list of asteroid properties or spectral lines. Catalogue_item can be limited to scalar quantities (including strings), and possibly to a single element. This presentation allows the user to search the catalogue from the TAP query interface.
  • sv (= spatial_vector): 


 Resource Type

Time

Freq

X

Y

Z

string / qualitative
Catalogue......
Catalogue Item......

Times Series

X






Dynamic Spectrum

X

X





Spectrum


X





Profile



X




Image



X

X



Map

X X

Spectral Cube


X

X

(X)



Movie (or Dynamic Map)

X


X

X



Volume (& 3D-shapes)



X

X

X (including Sparse)


Cube.....
  • No labels

9 Comments

  1. ev added in 2018 for events

  2. Unsure why we removed spatial_vector in 2016. They can appear in a catalogue, but are not catalogues themselves - just vectors… Now that we have actual catalogues (in VizieR), it becomes very clear that they cannot be handled in a similar way. There may be an ambiguity about vectorial maps, but that's all I see

  3. Practical request for a new "Photometric function" type, name TBC (= any quantity against one or several illumination angles).

  4. The idea of the dataproduct type is to tell about the dimensionality rather than the content (for most cases). Using a term like "photometric function" would prevent to reuse the same term for other parameters proposed against the phase or orientation of on object. I remember that this kind of fuzzy mixing between dimensionality and parameter content was our main issue with the SPASE measurement type. There are use cases in magnetospheric physics of radio emission probability maps, with axes that are phases and angles. 

    I have the following products in preparation: https://mdpad.obspm.fr/_XdxbU_uQHK2cyeyIVSWxA. For each image: the horizontal axis is the longitude (or phase) of the observer in the planetary frame, and the vertical axis is the phase of a Galilean moon with respect to the observer.

    So having a way to tell that data products are containing parameters on a "phase" related coverage would be very good. There are also use cases in astronomy with pulsars, for instance. 


  5. Unsure I follow you (same as orally some days ago -) To me your examples are like photometric functions. The quantity is provided in measurement_type

  6. proposed in new version (I'm still editing that page): 

    • pf (= photometric function): scalar or vectorial measurements along 1 angular dimension, e.g., phase or polarization curves, phase functions, emission-phase function sequences… Does not handle variations along several angular axes.
  7. + that was already clear in past discussion I think, dp_type relates to dimensionality + nature of X axis and associated processing (to select visu tools). Otherwise we wouldn't need profile / spectrum / time_series. Here we have photometric tools in preparation (via SSHADE). 

    Am I missing something? I can't see your ex, but they seem to be phase against phase… and the actual phase is in Y, rather than X

  8. OK, then we agree and now I understand where I mixed things up (smile) 

    Let me change my comment (I didn't see the changes when I wrote it): I don't agree with the proposed "pf" term, at least not as proposed. Introducing "photometric" in the term name seems very restrictive to me. A bit like astronomy using "light-curve" for time-series (they were also assuming that photometry only can change with time).  

    There are several discussions in parallel on dataproduct types (also used in ObsCore). The "phase" axis is something that was brought up by the radio astronomy interest group discussion. I linked the two issues, and I was thinking of how to find a common solution. Clearly the UCD path makes it simpler. 

  9. after offline discussion, I'm ok with the new term, since there are immediate use cases.