Notes from AAS IVOA footprint tag up

[Gretchen Greene]

Meeting Minutes from AAS Footprint Tag-up

Attendees: 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.

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


On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com> wrote:

> Hi folks,
> 
> We will be having a tag up on Tuesday, 1:00 in the exhibit hall snack table area, to talk about footprint specification standards to take advantage of a few folks present.
> 
> I will post our discussion notes to the DAL group to keep the communication flowing.  I am hopeful we can work toward assembling elements of a working draft spec for the spring interop.
> 
> cheers, Gretchen
> 
> Sent from my iPad