LSST will require the ability to map between a selected point on the sky and the tile in one or more fixed sky tessellation systems that contains that point. For LSST, this will be needed for at least:

• the LSST skymap system of "tracts" and "patches"
• HEALPix tiles at a specified order
  and it may also be useful to support the Qserv sky partitioning scheme (this would be more of interest to developers than end users).

Other common sky tessellations exist (HTM, Toast, etc.) and may be of interest to other Firefly applications. In addition, many sky surveys define their own tessellation schemes.

Some tessellations are exclusive - any given point belongs to one and only one tile - and others are overlapped with a point potentially belonging to more than one tile, but typically with only one marked as "fiducial". The latter is true both of the LSST tract-patch system and of the Qserv partitioning system.

I suggest that we define abstractions for this concept in Firefly and then provide implementations for the tessellations that LSST requires.

A basic set of functions needed might be:

• starting from a point, obtain the IDs of all tiles containing it, and the ID of the unique fiducial tile containing it
• starting from a tile ID, obtain a region description for the boundary of the tile on the sky, in a form that Firefly can use to draw the region on a sky image or on an x-y plot in sky coordinates, and the boundary of the fiducial region of the tile on the sky (this specification might be in the form of a Java class)
• if different from the "drawable" boundaries, obtain (a) specification(s) for the tile boundary/ies usable in ADQL (and therefore TAP) queries (this specification must be in the form of a text string usable in a query)

As conceived, this ticket is about static sky tessellations. However, I am aware, as I write it, that there is considerable overlap with the concepts involved in associating a point on the sky with the identities and borders of images that contain it. When the time comes to implement this ticket, that should be part of the engineering thinking that goes into the implementation.

Note that this ticket is not intended to require, for instance, that Firefly eventually have a native ability to navigate the LSST tract-patch system. An acceptable implementation might involve a call to a micro-service in the LSST Science Platform that does the (ra,dec) => (tract,patch) translation. But the Firefly-level abstractions need to make it easy to connect to such a service.

On the UI side I am imagining that the existing "upper right" pixel-coordinate-readout display in Firefly could be enhanced with additional application-defined options to display tile IDs associated with an image point.