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 sky in ~3.5 years of observing. After a number of years of observing there will be many overlaps between observations taken for different projects, 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 in  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 re-gridded  and sub-sequently co-added.

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 the sky"
  
• (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)  with 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 system (2) and hence the pixel-grid (3).

A preliminary tiling and pixel grid scheme has been defined for OmegaCAM (Class PlateSystem.py) which involves  22.717 Square degree fields for the Southern hemisphere with on average about 5% area overlap between adjacent fields (see figures skygrid_*.ps).
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 definition.
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 grid.

Benefits of adopting such a scheme, both for  Survey preparation and 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 filter 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 for re-gridding. (even when combining OmegaCAM data to that of other Wide-field-imager data in the archives, WFI@2.2m, WFC@INT, MDM).
  
• After many years of operation,  the co-ordination will build up  a much more complete and smooth archive which will provide a valuable survey in itself, beyond the goals of the individual projects.
  

Notes:
-- 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 the 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  for 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 Platesystem.py :

• It's in Python, works in Python version 2.3 or higher and requires the Python plot package DISLIN.
For AstroWise  it is a working prototype of the Class PlateSystem which has a range of applications
footnote: the Class PlateSystem is very nice example of the effectivity of object oriented programming in Python

1.  it can be used to design a rectangular grid (tiles) on the sky with free parameters field of view, nominal overlap and minimal overlap;  it plots and prints the grid (tiles) - the script is clever in making the grid smooth and avoiding big jumps.
2. 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 re-gridding the jittered/dithered input images to an output frame (tile). This way all images produced by the pipeline are on the same tiles, AND also on the same pixelgrid.
  

• This method can  be used as a survey preparation tool,  by 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 a 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.

---