Optimizing OmegaCAM/VST Surveys: Tiling and Pixelating the
A plan for coordination of coordinates for both Survey data
taking and processing
On average OmegaCAM will observe ~20 fields per night,
which for say
300 nights per year equals to ~6.000 fields /year, which roughly
corresponds to the equivalent of the full area of the Southern
~3.5 years of observing. After a number of years of observing there
will be many overlaps between observations taken for different
and clearly there is a lot to gain by organizing the fields in advance.
(footnote: for the forseen 10 year lifetime of
VST/OmegaCAM this corresponds to observing the equivalent of the whole
Southern hemisphere in 3 different bands with 0.20 arcsec pixels)
The AstroWise system will ingest the majority of these observations
federated archives distributed over at least NL, D, F and I.
The archive will contain the raw observational data together with
processed, astrometrically and photometrically calibrated, science
images, which will be published directly from the archives
(datawarehouses) to the VO.
The science images are often taken with multiple exposures (dithers) on
the telescope. In the image pipeline these images are
Obviously, with this enormous amount of observations there is a lot to
gain by co-ordinating:
- (1) the choice of the field centers of the observations : "tiling
- (2) the choice of the coordinate reference positions when
projecting the coordinate system of the re-gridded images
- (3) the choice of the pixel positions (pixel-grid)
respect to the reference positions: "pixelating the sky"
For OmegaCAM we propose a standard set of field centers for the
observations (1), also to be used for the reference coordinate
(2) and hence the pixel-grid (3).
A preliminary tiling and pixel grid scheme has been defined for
(Class PlateSystem.py) which involves 22.717 Square degree fields
the Southern hemisphere with on average
about 5% area overlap between adjacent fields (see figures
Fields are positioned in 95 strips of constant
Declination, separation in RA is optimized to maximize continuity
in declination direction, which is the more complex part of the
In the re-gridding process, science images are projected with the
traditional gnonomic tangential projection with pixel size 0.2
arcsec, with projection centers
identical to observing field centers. This defines a complete sky pixel
Benefits of adopting such a scheme, both for Survey preparation
for data reduction are:
- When observations of different projects enter the archives,
continuity of sky coverage is optimized
- When observations of different projects enter the archives taken
at either different filters or at different epochs of the same area of
the sky, observers can get immediately the other epoch or
information for the whole field.
- The tedious interpolation of images is done only once
- Stacking /co-adding/differencing images taken at different
epochs/bands/projects can be done immediately without the need
re-gridding. (even when combining OmegaCAM data to that of other
Wide-field-imager data in the archives, WFI@2.2m,
- After many years of operation, the co-ordination will build
a much more complete and smooth archive which will provide a valuable
survey in itself, beyond the goals of the individual projects.
-- Of course observers do have the option to override the tiling when
there are good scientific reasons to do so.
-- We are in contact with VISTA on this scheme, but unfortunately
larger field of view of Vista does not really match.
-- Putting integer number of squares covering the surface of a sphere
is an art in itself. Further improvements and insights are very welcome!
Formal ESO status is
- in OmegaCAM (=ESO) user manual we advise to use
the tool for
sky tiling for preparing observations (i.e use tile ra decs
pointings). There is freedom to ignore this advise
- ESO agreed to use the tiling/pixelating in the output of the
DFS pipeline. We do this also in the AstroWise image pipeline.
A few lines on the tool itself
- It's in Python, works in Python version 2.3 or higher and
the Python plot package DISLIN.
For AstroWise it is a working prototype of the Class PlateSystem
has a range of applications
footnote: the Class PlateSystem is very
nice example of the effectivity of object oriented programming in Python
- it can be used to design a rectangular grid (tiles)
with free parameters field of view, nominal overlap and minimal
overlap; it plots and prints the grid (tiles) - the script is
making the grid smooth and avoiding big jumps.
- The default values actually correspond to the tiling we have
tentatively adopted for OmegaCAM.
Once the Class is instantiated it can be applied in different ways:
- One can ask for the ra,dec center of the nearest tile for a
given input ra,dec. The AstroWise image pipeline uses this when
jittered/dithered input images to an output frame (tile). This way all
produced by the pipeline are on the same tiles, AND also on the same
- This method can be used as a survey preparation tool,
querying for the ra,dec of the tile closest to my target ra,dec
- it can also be used to plot and print the
mosaic of tiles for
given range of ra, dec as a survey preparation tool.example plot: tiling the pole
At the bottom of the script text some examples are included which are
executed when running the script as is.
The script does nothing in automatic OB creating for large numbers of
observations, and we are very interested in co-operating with
VISTA for that part.