Registry science metadata
amsr at jb.man.ac.uk
Wed Apr 30 07:44:21 PDT 2003
On Thu, 1 May 2003, David Barnes wrote:
> Hi Anita,
> I don't know whether the following entries come from you or
> Hanisch, but in:
> > COVERAGE
> > "ramin" decimal (degrees)
> > "ramax" decimal (degrees)
> > "decmin" decimal (degrees)
> > "decmax" decimal (degrees)
> I'm not at all clear on why we explicitly choose ra and dec
> as the required tags to define coverage. They're not always
> particularly meaningful. For example a study of the Galactic
> plane to +- 5 degrees Galactic latitude would have ra and dec
> extents which suggest a much larger area survey than what has
> actually been accomplished.
> I also imagine there are plenty of use cases where one might
> want to search on Galactic lat and long constraints rather
> than ra and dec. To accommodate this, presumably registry
> searching tasks/facilities will have conversion capabilities
> built in, but that simply doesn't help in the case above.
> So, given that conversion facilities will be ubiquitous,
> why don't we take advantage of all the hard work done in
> describing the various reference frames (eg. Calabretta et
> al.) and allow the coverage to be specified by something
> more like:
> "directionsystem" string (J2000,B1950,GALACTIC, ...)
> As usual if this has been discussed in the past or elsewhere,
> just point me to that and I'll go and fill my brain with the
> necessary prerequisites!
These are good points worthy of discussion. Bob Hanisch et al.'s document
does allow for a greater variety of ways to describe angular coverage,
similar to what you suggest.
However, in discussions in AstroGrid, we felt the list of ways to outline
angular coverage was becoming rather large and complex. There was general
agreement (I think!) that the ideal system would be a form of indexing.
The sky is divided into fairly coarse bins so that the total number can be
searched effectively instantaneously (10^4? 10^5?) and each dataset has a
matrix of 1's and 0's indicating whether or not there *might* be data in
each bin (eg a bin overlapping the error circle of a source position, or
way down in the field of view of an interferometer, would still be a '1').
This could be drawn up on ingestion of a dataset.
But we don't yet have the algorithm to do that! So in the meanwhile - and
as a higher-level filter in any case - we will adopt simpler limits. I am
suggesting these are, initially, just min and max RA and Dec. This is
just for the ResourceMetadata held by the Registry, to be used to see if
it is even worth looking at a data set in more detail. So we may waste
time looking in the wrong corners of a dataset which only covers the
Galactic plane, but it fullfils the minimum requirement of not falsely
rejecting useful datasets. I am also assuming that we precess all the
limits to J2000 - for the above reasons high accuracy does not matter at
In effect this is a subset of Bob et al's requirements
- Region Name: box
- cframe : FK5
The main reaosn for this is that it can be specified automatically using
readily available algorithms - finding extrema and using standard
coordinate conversions. The other suggestions from Bob et al. - and
AstroGrid - (e.g. polygon, indexing) require work seems to me less urgent
than getting the skeleton Registry up and running. For this reason it is
a good starting point for the International Registry which does not want
to be more complex than more local ones, I woudl think.
Moreover, we should decide what extra details we do need in the light of
tests against real science cases, e.g. the ones which Mark Allen has
proposed and the other AstroGrid ones. And, of course, for some data sets
angular coverage is not relevant anyway...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
More information about the registry