Notes from AAS IVOA footprint tag up

[Alberto Micol]

This is a fantastic step ahead! Thank you so much.

Now, taken by enthusiasm as I am, I want to immediately implement it.

Would you know whether a library that can parse, digest, and maybe plot
a generic STC-s region exist?

I need something that can deal with, eg:

Union ICRS TOPOCENTER
(Circle 180 10 20
Circle 190 20 20
Intersection
   (Circle 120 -10 20
     Difference  (Circle 130 -10 20  Circle 125 -10 2)
    Not  (Circle 118 -8 3)
   )
)

<thinkingloud>Mmmhh... do I really need such  a complex beast?</ 
thinkingloud>

I think that:
- 70-90% of the DAL cases will have to deal with a single polygon;
- 10-30% of the cases will be for a simple UNION of polygons (eg for  
multi chip cameras)
- 1% of the remaining cases will be for quite complex regions, like  
the one described above.

Please correct me if you think my stats do not represent real *DAL*  
usage.
Looking at the DAL standards already available or in the making, DAL  
does not seem
concerned by more complex shapes like for example the sky coverage of  
a survey
(see for example the final SDSS sky coverage: http://www.sdss.org/includes/sideimages/orangespider.html 
  ).

Therefore I find asking asking myself:

<morethinkingloud>

- how many providers will implement a complex library to handle all  
possible the cases?

- does such library already exist (and for which language)?

- otherwise, is it foolish to suggest to limit the usage of an STC-s  
region in DAL to few representative cases
that cover 95% (or more) of the DAL cases (e.g. single polygon, union  
of 2 or more polygons, plus maybe the NOT operator to describe holes) ?

- otherwise, is there the need (for lazy providers) to have two  
different votable fields:
   (1) s_region: the full and potentially complex region,
   (2) s_polygon (invented here): the higher level polygon that  
inscribes the s_region
  ?   (s_polygon would be a LOCATION, while s_region a SUPPORT, in  
chardm  speak);

- is it maybe just me being too lazy?

</morethinkingloud>

Just thinking loud, to stimulate discussion (but I think lowering  
implementation costs is always good).

Eager to know what you think,

Thanks a lot, it is really a great news,
Alberto


On 11 Jan 2012, at 16:56, Gretchen Greene wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20120118/95d2bbbf/attachment.html>