Page tree

Versions Compared


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


  • Mandatory :
    processing_level -mandatory
    service_title –mandatory
    publisher -mandatory???
  • Optional - TBC
    spatial_coordinate_description  (default = body-fixed or J2000)
    spatial_origin  (default = body center or SS barycenter? Or observer location)
    time_origin  (default = observer)
    time_scale (default = UTC – no other values allowed in data services? [only in computational services, e.g. ephemeris])
    Same values to be used in registry declaration 


Support for PDS3 detached labels (proposal)

access_format = "PDS3label" (it has to be here: we need to know that there is a detached label)
then access_url points to the label, and data_access_url points to the file (param is mandatory in this case - although the data file name is in the label, it can be in another directory)
A script can then recover both files and do something with them. This mechanism can be extended to other formats with detached labels (ENVI…).
Check solution with datalink first
Solution with datalink seems OK: detached labels provided under datalink_url in a table - although no attempt made to read them from the portal, yet.


Need to clean up current doc (2.0). Utypes are = DM fields. They are supposedly used to identify the meaning of parameters and help e.g. tools to grab required quantities - This will not work in some areas though, e. g. with spectral tools as they currently use UCD instead of Utype for this purpose (not many tools appear to actually rely on Utype in fact). See discussion here for usage (a bit old?):

To handle this in practice:

  • Associate each parameter to a specific Utype in EPNCore - all names need to start with the epncore: prefix/namespace.
  • Then map epncore Utype to other DM (find equivalent parameter, or trace back the original templates of EPNCore parameters - often from ObsCore)
  • Reuse Utype from other DM each times it makes sense - TBC: the epncore: namespace is still required (even when using Utypes from other DM)
    This allows tools to handle EPNCore parameters like existing parameters from other DM, i.e., with no specific implementation
    Pb is that small differences in the use of parameters may preclude reusing the same Utype (TBC: does that applies to units also?)
  • Cross our fingers: known Utype (from other DMs) may be usable in existing tools (e.g. a tool supporting Provenance would grab equivalent info in EPN-TAP services transparently)
    Unclear if the use of the namespace makes it more complicated in tools.


Example of V1 to V2 conversion with APIS database: