RE: Scope of registry

My 2 cents ---

I talked about this very briefly in Munich -- I think that the field-of-view or footprint for any survey is a 'fractal', and the answer depends on the context of the question. Take for example the SDSS: the precise footprint is the union of 47 stripes, each of them defined in their own spherical coordinate system, each built from another 12 camcols, with some overlaps among them. If we want to represent this in full precision, we need to define 47 speherical systems, and a complex union/intersection of 47*12 spherical rectangles, where some of the boundaries are small circles. Add to this a bunch of excised areas, like areas of poor seeing, regions around bright starts, geostationary satellites, metorites, and we are talking about thousands of spherical polygons for a precise definition. To provide this whole information is always an overkill.

I can think of three different contexts one wants footprint info:

(i) whole sky -- here we do not care about the full complexity

	of the footprint, for SDSS it would be enough to say that
	gb>30 and the 3 southern stripes
(ii) on 6-10 degree scales -- here we hand an area definition, and
	ask for its intersection with the survey outline
(iii) less than a degree scales -- here again we pass an area definition
	and we request the precise intersection with the area

Here (ii) and (iii) are similar, but not identical: (ii) would still return an approximate answer, while (iii) would always return the precise one. I envisage a heuristic simplification (optional) of the boundaries for (ii), so that we never return more than ~20 spherical polygons to characterize the footprint.

These can be easily implemented as a simple web service, with two functions:

(i):     AREA footprint(void);
(ii)-(iii)	AREA intersect(AREA in_area, float tolerance)
	or AREA intersect(AREA in_area, int npoly)

where the tolerance or npoly determine the level of approximation. The AREA is a representation of an arbitrarily complex region of the sky, I presume in terms of spherical polygons.

We do need to use extended spherical polygons -- using only great circles as arcs is not going to be good enough to represent drift scan surveys, like the SDSS, where the camera sweeps an approximately cylindrical surface. We do need to allow for arcs which are small circles.

This is the reason why in the SDSS we started to use 3d Cartesian representations of polygons. Every edge of a spherical polygon is represented by a 4-vector, describing the equation of a plane in 3D. The edge is the intersection of the plane with the unit sphere. The Cartesian coordinate system is tied to J2000 ICRS. This has the advantage that all the boundaries of the SDSS stripes for example can be cleanly represented this way, without having to introduce new spherical coordinate systems for each.

The 4-vector is (cx,cy,cz,d). Here (cx,cy,cz) form a 3D normal unit vector of the plane, and the d is the offset from the center along the normal. Thus great circles have always d=0. An intersection of N such planes forms a CONVEX, this is a convex polyhedron in the 3D sense, and the union of CONVEXes form a DOMAIN. These names are lifted from computational geometry.

DOMAIN := DOMAIN OR CONVEX
DOMAIN := DOMAIN OR DOMAIN
CONVEX := CONVEX AND CONVEX
CONVEX := CONVEX AND EDGE

A cone search is a single constraint, where cx,cy,cz point to the center, and d=cos(radius).

Note, that this is a pure, and rather abstract notation, independent from our HTM library, which performs a particular "rendering" of the sky in terms of spherical triangles, and can compute the set of covering triangles for an AREA defined this way.

I would like this definitions of an AREA be considered for the data model because I think that they represent an extremely flexible way the describe region or areas on the sky, from hundreds of degrees in size to milliarcesonds.

Cheers, Alex

-----Original Message-----
From: owner-metadata-at-us-vo.org [mailto:owner-metadata-at-us-vo.org]On Behalf Of Tony Linde
Sent: Wednesday, February 05, 2003 6:40 AM To: Clive Page; registry-at-ivoa.net; metadata-at-us-vo.org Subject: Re: Scope of registry

Small point Clive: registry list address is 'registry-at-ivoa.net' and not .org.

The point you raise is interesting and is on the border line between the 'minimal required' standards and the 'extensions' each registry might implement. The ability to query what part of sky a resource (if it is that type) covers is necessary; I'm not sure we need to standardise how this is implemented.

> - We need a way to represent the shape of the field-of-view, some are

Agreed. Both in a query to the registry and in the results returned.

> - We need a way to gather the information from the individual archives: it
> may not be possible to do this by robot, it may need a human to get and
> convert the data to some uniform format (XML-based I'd guess).

It should be done by robot but it'll be up to each data centre to make it available in one of a few standardly accessible ways: eg xml files in set location, service with specific api.

> - The Registry will be quite a lot larger if it contains this
> information,
> so the design, even if it omits this type of data initially, must be
> suitable to scale to this size in due course.

This is definitely outwith the scope of IVOA standards: it'll be up to individual projects to determine how to achieve this.

> So I would urge the Registry designers to consider providing this
> fine-grained information from the outset, if at all possible.

Again, there is no single Registry. Each project will implement this facility in their own way. They need the ability to respond to fine-grained queries but the project can decide for itself whether to include this in their implementation of their registry or to farm such queries out to the individual resources. AstroGrid will be fine-grained but other projects may decide differently.

Cheers,
Tony.

On Wed, 5 Feb 2003 09:07:57 +0000 (GMT), "Clive Page" <cgp-at-star.le.ac.uk> said:
> I've been visiting the NeSC in Edinburgh for the last few days so haven't
> had time to read all the Registry-related emails carefully, so apologise
> if this posting duplicates something already covered. But most of the
> discussion I've seen is of computer science topics, and not much on
> scientific requirements.
>
> It seems to me that one of the most valuable things the registry should
> do
> is to tell the astronomer about _all_ resources which potentially have
> information about some point (or small patch) in the sky - this is the
> obvious extensionh of the cone-search which is widely agreed to be a
> priority VO service. The user wants to specify the name of an object,
> to
> be turned into coordinates by Simbad/NED, or an (RA,DEC) and perhaps a
> small radius, and be told where there are (or may be) useful information.
> In many (most?) cases the user will also restrict the query with a choice
> of waveband (tell me all radio observations for example) or a limit in
> say
> time of observations (all pre-outburst observations of this star).
>
> For the well-known surveys this presents few problems, but there are lots
> of observatories which have observed the sky piece-meal. Many of these
> have on-line observing logs. For example you can search the archives of
> the HST, or Chandra, or XMM-Newton to see whether your bit of sky has
> ever
> been in their field of view. This is also possible for many ground-based
> telescopes, and I guess all of them before long. This information is at
> present obtainable only with great difficulty, as the archives are widely
> scattered with very diverse user interfaces. In principle the Registry
> could make this _much_ easier. I think we ought to aim to make this a
> practical reality.
>
> There are some obvious difficulties:
>
> - We need a way to represent the shape of the field-of-view, some are
> circular, some rectangular, or odd shaped (e.g. HST). The data modelling

> people have discussed this, but not yet solved it.
>
> - We need a way to gather the information from the individual archives:
> it
> may not be possible to do this by robot, it may need a human to get and
> convert the data to some uniform format (XML-based I'd guess).
>
> - The Registry will be quite a lot larger if it contains this
> information,
> so the design, even if it omits this type of data initially, must be
> suitable to scale to this size in due course.
>
> Although the difficulties of data gathering and implementation are
> non-trivial, I think they are tractable, and that the resulting gain in
> functionality for the astronomer-in-the-street would be considerable. A
> registry which could provide this hard-to-get information would put the
> VO
> on the map as something actually useful (a lot of astronomers, at least
> in
> the UK, think the VO movement prettyn much a waste of time and money).
> So I would urge the Registry designers to consider providing this
> fine-grained information from the outset, if at all possible.
>
>
> --
> Clive Page,
> Dept of Physics & Astronomy,
> University of Leicester, Tel +44 116 252 3551
> Leicester, LE1 7RH, U.K. Fax +44 116 252 3311
>
>

__

Tony Linde                       Phone:  +44 (0)116 223 1292
AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
University of Leicester          Email:  ael-at-star.le.ac.uk
Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org

--
http://fastmail.fm - The professional email service