Page tree
Skip to end of metadata
Go to start of metadata

Current situation

So far, spatial footprints are provided in EPN-TAP / EPNCore through:

  • Spatial coordinates C1_min/max and C2_min/max - as bounding boxes (one connected area)
  • s_region (from ObsCore), using a syntax which is not entirely defined (STC-S string) - also expected to be one connected area, polygons only

The VESPA portal provides quick visu of footprints: 

  • Bounding boxes are sent to Mizar1 
  • s_region are sent to Aladin

TOPCAT also provides very helpful support for plotting s_region.

TAP & ADQL allow ~easy searches on intersections/overlaps.

Drawbacks / limitations:

  • Bounding boxes are really a minimal approach: they can be much larger than the actually footprints and there may be a singularity when a pole is included - however this is easily provided and consistent with PDS parameters.
  • s_region are ambiguous: the sense of rotation is not clearly defined/respected in astronomy services, this is even worse for planetary frames which are mostly E-handed. Providing point locations requires some tricks.
  • This only works on bodies where lon/lat description is relevant (not 67P, which has degenerate lon/lat system — check with J. Griger's projection solution, though).

MOC usage

MOC are potentially even more useful:

  • MOC 2.0 is consistent with non-sky coordinates and includes an ascii serialization scheme (also for STMOC).
  • MOC ascii strings can be included in tables (they are not that long)
  • They describe non-connected areas very easily
  • They solve the ambiguities of STC-S strings
  • Footprints can be extended to include time coverage if required (STMOC, in MOC 2.0)
  • Spatial operations are more powerful and quicker than s_region
  • Composed MOCs can link to progenitors
  • TOPCAT & Aladin provide handy visualization of MOCs

This has been discussed in a VESPA workshop. It is very clear that we want to include MOCs in EPNCore!

A more complete use case on the sky is available here (spatial MOC only). 

Practical implementation

Open questions: 

  • Do we allow including MOCs in the (mandatory) s_region parameter? — probably not, as this would make it difficult to identify STC-S strings from MOC strings. It would also break the correspondance with ObsCore
  • Dedicated optional parameter? Probably yes, since MOC can be derived from STC-S strings. This is often called *shape in astro services, with UCD = phys.angArea (TBC for STMOC)
  • Need to foresee the use of parameters providing several scales (quicklook vs detailed info)? (done in some astro services)

MOC spatial coverage is handy:

  • on regular bodies only (not 67P!)
  • not limited in resolution (10 m on Mars would be ~ 1" which is order 18, whereas max MOC scale = 29) - TBC with lander data though (if it makes sense - would be horizontal coordinates?)
  • to provide all kinds of 2D observational footprint (including points, relevant scale TBC)
  • to provide region / unit areas, e.g. from a geological or spectral classification

MOC time coverage is relevant:

  • To include space experiment / telescopic observation time lines, especially on evolving targets (Mars, Venus, 67P…), at diurnal scale (order ~ 25)
  • Probably not to handle local time scale on planets (depends on location, plus TMOC is based on JD), although… 
  • A possible way to select by season (cyclic) is to provide an independent time line for target's Ls - but we already have a dedicated parameter
  • For events (µs resolution available, order 64)


  • Bounding boxes (C1/C2) are simply the coordinate of frame corners. This is usually known from observing parameters, or can be computed easily (e.g. SPICE or webgeocalc, topography can be taken into account). Need to account for 0-meridian crossing, and there is an ambiguity when a pole is included (it seems that tools assume the actual region is the smaller one). 
  • s_region can be more tricky, as this requires to sample a contour. May require to untangle contours for complex acquisitions (mosaics, spectral cubes…)
  • MOC are easily derived from s_region, but there may be a better way in complex cases - eg, with spectral cubes, see if we can compute a global MOC by merging MOCs of individual spectra.

Possible use cases:

  • Geological units on Mars (or 67P, but need to address coordinates issue first)
  • easy: Mars_craters (from s_region or location & size), HST_planeto (from s_region, on sky)
  • VVEx from addition of smaller footprints (individual spectra) - the contour itself is tricky to recover. Spectrum nb/ID can be included as progenitor, STMOc can be used (preferably with time of cube acquisition)
  • The Saturn use case from Aladin has applications to searches for serendipitous observations of moving targets (see ESAsky approach)

  • No labels
Write a comment...