[Fwd: RE: Scope of registry]
Marco Leoni
Marco.Leoni at eso.org
Wed Feb 5 07:02:16 PST 2003
I'm forwarding this email to the IVOA Data Model mailing list.
-------- Original Message --------
Subject: RE: Scope of registry
Date: Wed, 5 Feb 2003 09:15:33 -0500
From: "Alex Szalay" <szalay at jhu.edu>
To: "Tony Linde" <ael at star.le.ac.uk>, "Clive Page" <cgp at star.le.ac.uk>,
<registry at ivoa.net>, <metadata at us-vo.org>
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"
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
--
------------------------------------------------------------------------
Marco Leoni <http://www.eso.org/%7Emleoni>
AVO <http://www.euro-vo.org> System/Software Engineer
tel: (+49 89) 3200 6560
fax: (+49 89) 3200 6480
European Southern Observatory <http://www.eso.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20030205/9dc44fdb/attachment-0001.html>
More information about the dm
mailing list