Notes from AAS IVOA footprint tag up
Arnold Rots
arots at head.cfa.harvard.edu
Thu Jan 19 10:49:11 PST 2012
We display a circle to indicate the search area, but for us it isn't
part of the footprint.
I am sure radio images would use circles.
- Arnold
Jonathan Fay wrote:
> What about circles?
>
> ________________________________________
> From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Arnold Rots [arots at head.cfa.harvard.edu]
> Sent: Thursday, January 19, 2012 7:52 AM
> To: Thomas Boch
> Cc: Gretchen Greene; arcops at head.cfa.harvard.edu; dal at ivoa.net
> Subject: Re: Notes from AAS IVOA footprint tag up
>
> 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/
> --------------------------------------------------------------------------
>
>
>
--------------------------------------------------------------------------
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