Notes from AAS IVOA footprint tag up
Arnold Rots
arots at head.cfa.harvard.edu
Thu Jan 19 07:52:08 PST 2012
CXC and HLA have footprint services with common ancestry.
Ours is written in Java and paints on Canvas.
I think the 10/90 - 30/70 split is optimistic.
50/50 is closer to reality and the multi-chip fraction will increase.
It also depends whether you count services or actual number of
footprints processed.
Catalog footprints will also be more complex.
For us the typical case will be:
Union ICRS TOPOCENTER
(Polygon ...
Polygon ...
...
)
Although there will be occasional footprints like:
Intersection ICRS TOPOCENTER
(Union
(Polygon ...
Polygon ...
...
)
Not
(Union
(Polygon ...
Polygon ...
...
)
)
)
- Arnold
Thomas Boch wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> 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
> >
>
--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138 arots at head.cfa.harvard.edu
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------
More information about the dal
mailing list