Notes from AAS IVOA footprint tag up

[Thomas Boch]

Hi Alberto,
> Would you know whether a library that can parse, digest, and maybe plot
> a generic STC-s region exist?
I asked a similar question 2 months ago. What I remember from the 
discussion is that :

- CADC has developed an STC-S parser in Java 
(http://code.google.com/p/opencadc/source/browse/trunk/projects/#projects%2FcadcTAP%2Fsrc%2Fca%2Fnrc%2Fcadc%2Fstc) 


- the AST C library, developed by David Berry, has a STC-S parser  
(http://starlink.jach.hawaii.edu/starlink/AST) and provides bindings to 
Python, Perl, Java, ...

Cheers,

Thomas

>
> 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 
>> <mailto: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/20120119/0931f1a0/attachment-0001.html>