Where the survey has detections. Click any cell to search it — the
cell becomes a polygon search over its own RA/Dec bounds, which is
the region the cell's count was taken over, so the two agree up to the 5,000-row
limit every search has. The search arrives with every column filter row
free, so you can narrow the cell by snr or mjd
without giving anything up; it used to spend four of the five saying where the cell
was.
Two things that link does not do. A polygon is not a cone, so a cell holding more than 5,000 detections reports “5,000 shown, and more matched” rather than the exact number on its tooltip — counting every match is affordable only under a cone's capped radius. And a cell that is both large and very dense can be refused rather than answered: a polygon's cost is estimated per row lying under it, so the 10° cell covering this catalog's densest patch comes out above the limit the portal answers without a cone. A smaller cell size is the answer — every cell at 1°, 2° and 5° is answered here. Hiding the fixture does not help, because the estimate counts the rows scanned rather than the rows kept, and neither does asking for fewer rows.
2,279 detections in 4 cells of 5.0°. Sky with at least one detection: at most 4 square degrees, or 0.009% of the sky. Mostly empty is the correct picture for now.
That is an upper bound, not a measured footprint. It is the area of the 1.0° grid squares that hold a detection, so a single detection claims a whole square and the sky actually observed can be orders of magnitude smaller — for the ZTF stand-in patch it is. The grid stays fixed at 1.0° whichever cell size you pick below, so the figure does not move when only the picture does. Measuring a real footprint needs the exposure outlines, which the stand-in data does not carry.
Cells are RA/Dec rectangles, so they are not equal-area — a cell near a pole covers
much less sky than one at the equator. Fine for finding coverage, not for comparing
densities across declination. Same data as JSON: /api/sky?bin=5.0