Basic Footprints with DAL services

---

Description

• informal coordination meeting minutes (Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold Rots, Doug Tody, Thomas Boch)

Summary:

The discussion focused on establishing agreement on the format of the metadata used to describe simple outline footprints, i.e. spatial regions, for basic DAL services, SSA, TAP, SIA etc.(ultimately we want a uniform representation for all such services). The issue of defining a general footprint service will be considered separately.

The issue of region specification follows a discussion thread on Utypes for regions. The minutes will be circulated to the DAL working group to see if we have considered valid points. A follow on action will be to draft a technical note on the agreed upon implementation. Having a standard description for the spatial region support will provide uniform format specifications across services and simplify client software handling of regions.

The current SSA, ObsCore (Observation), and draft SIAV2 specs already provide a mechanism for this based upon Characterisation. The main change required is to generalize the STS-S region specification used to support more complex multi-area regions, particularly where there is substantial blank area within the overall region covered.

As currently defined in the ObsTAP/ObsCore specification and in SSA and the draft SIA v2, spatial regions will adopt as a default coordinate system ICRS. The region will be defined as an STC-s string representation of the standard Space Time Coordinate data model. The Utype will follow the Characterization data model as already used in SSA, ObsCore, etc., i.e.,

Char.SpatialAxis.Coverage.Support.Area

The ObsCore column name "s_region" is suggested to identify this column but is not mandatory.

The "semantic type" of the region is defined as AstroCoordArea. This is distinct from the Utype, which may have been source of confusion in the earlier Utype discussions.

Compound Regions:

The main change would be to allow even this "simple" service region metadata field to be used to describe compound regions that have multiple areas described. This is required by observations from some modern detectors [eg?] which can simultaneously observe multiple spatial regions.

An example (will provide more accurate example in technical note) of this:

UNION (Polygon ra1 dec1 ra2 dec2 ra3 dec3 ra4 dec4 Polygon ra1 dec1 ra2 dec2 ra3 dec3 ra4 dec4)

Compound types include union, intersection, negation, difference.

Some current service implementions (e.g. HST?) already implement an earlier version of this and would need to be updated along with dependent client applications. We would like to agree on timing for some of the reference implementation for clients to utilize the new representation.

In the case of multiple coordinate systems, this is special client case that will be addressed with more complete footprint service spec. The general Footprint service specification will be a more complete utility which addresses footprint capability metadata registry descriptions, methods for accessing and manipulating regions, spatial tessellation, etc., not covered with basic access protocol extension...

Technical Note draft

Discussion and Feedback

---