Event contains a single linear feature detected with all its measured parameters on a single Frame. Event is intended to be used as the basic object on which work is done, as it encompases all information (times, frame, points…) required. While that may be true, Event is still composed of multiple smaller movimg pieces with which it can have complex relationships with so there are some things worth remembering when working with Event.

In short:

  1. Non-prefixed coordinates are properties of the Event class (i.e. x1, y1…). The column names are prefixed with an underscore (i.e. _x1, _cx1…)
  2. always change column values through properties since many of them have additional sanity and caveats checking imposed on them
  3. Points interpret the coordinates in frame-referenced mode by default
  4. Frame properties can not be changed through Event
  5. If Frame is changed the changes won’t reflect on Event untill DB commit is made.

Longer explanation:

Point objects handle the coord conversions and maintain consistency among the coordinates during interactive work. The table values are hot-wired to Point objects through composites and properties. It is easy to commit a mistake to DB when working with column attributes directly and leave the DB in inconsistent state that can’t be fixed without manually editing the value.

Point objects are dependent on the Frame object to provide a reference point for conversion between the two coordinate systems. Frame should update the Event’s coordinates, but this is only enforced at instantiation time. Enforcing consistency only at instantiation time lets us leave the well-defined CCD coord system into ccd gaps and then snap2ccd before commiting. But at the same time is possible not to see the changed values update immediately when a Frame attribute is changed. The coordinates will be updated once a DB commit is made. Additionally, the Event to Frame relationship is many to one, which means there can be many events on a Frame. Updating a Frame requires reflecting that change to all Events on it.

Point objects will issue warnings or errors if inconsistent situations arise. When a warning is issued, unless it’s clearly understood and expected, the best course of action is to issue a rollback. Otherwise DB could be sent to an inconsistent state.

The start/end times are stored in the DB in the SDSS-TAI format. There are some caveats when converting this time to MJD. See: https://www.sdss.org/dr12/help/glossary/#tai

class lfd.results.event.Event(frame, x1=None, y1=None, x2=None, y2=None, cx1=None, cy1=None, cx2=None, cy2=None, start_t=None, end_t=None, coordsys='frame', **kwargs)[source]

Class Event maps table ‘events’. Corresponds to a single linear feature detection. Contains the measured properties of the feature and links to the Frame on which it was detected.

  • id (int) – PrimaryKey, autoincremental
  • _run (int) – run id (ForeignKey)
  • _camcol (int) – camcol id (ForeignKey)
  • _filter (str) – filter id (ForeignKey)
  • _field (int) – field id (ForeignKey)
  • frame (sql.relationshitp) – Frame on which the linear feature was detected, a many to one relationship to frames
  • x1 (float) – x frame coordinate of point 1 of the linear feature
  • y1 (float) – y frame coordinate of point 1 of the linear feature
  • x2 (float) – x frame coordinate of point 2 of the linear feature
  • y2 (float) – y frame coordinate of point 2 of the linear feature
  • cx1 (float) – x ccd coordinate of point 1 of the linear feature
  • cy2 (float) – x ccd coordinate of point 1 of the linear feature
  • cx2 (float) – x ccd coordinate of point 2 of the linear feature
  • cy2 – y ccd coordinate of point 2 of the linear feature
  • p1 – see class Point composite Column mapping of x1, y1 to a point p1
  • p2 – see class Point,composite Column mapping of x2, y2 to a point p2
  • start_t – if possible, the time of the first detection of the linear feature on the frame, see class BasicTime
  • end_t – if possible, the time of the last detection of the linear feature on the frame, see class BasicTime
  • lt – not very usefull, see class LineTime


A Frame object reference is required. See lfd.results.frame.Frame for documentation. At minimum, supply the Frame object and coordinates of two points defining a line:

>>> foo = Event(Frame, 1, 1, 2, 2)

By default the coordinates are considered to be in “frame” coordinate sys. Optionally specify the “ccd” as the reference coordinate system:

>>> foo = Event(Frame, 1, 1, 2, 2, coordsys="ccd")

Optionaly all values could be supplied:

>>> foo = Event(Frame, 1, 1, 2, 2, 1, 1, 2, 2)

or on an example of a different CCD (4, ‘i’):

>>> foo = Event(f, 1, 1, 1, 1, 11377, 27010, 11377, 2710)

or verbosely:

>>> foo = Event(frame=Frame, x1=1, y1=1, x2=2, y2=2, cx1=1, cy1=1, cx2=2,
                cy2=2, coordsys="frame")


When specifying coordinates in the ccd coordinate system be mindful of the fact that coordinates (0, 0) in ‘ccd’ frame are upper left corner of the ccd array (camcol 1, filter ‘r’). It is not possible to have CCD coordinates (1, 1) or (2, 2) except on the first chip of the CCD-array. If the Frame reference is with respect to some other camcol and filter the ccd coordinates must, otherwise an Error will be raised.

It is possible to submit start or end time of the linear feature in any the following formats: Astropy Time object, float number in mjd format, float number in sdss-tai format:

Astropy Time Object - supply an instantiated Astropy Time Object:

>>> st = astropy.time.Time(58539.0, format="mjd")
>>> et = astropy.time.Time("2019-02-25 00:00:10.000")
>>> foo = Event(frame, 1, 1, 2, 2, start_t=st, end_t=et)

Any Astropy Time supported format such as mjd, iso, isot, jd etc…

>>> foo = Event(frame, 1, 1, 2, 2, end_t=63072064.184, format="cxcsec")

or in the SDSS modified tai format:

>>> foo = Event(frame, 1, 1, 2, 2, start_t=4575925956.49, format="sdss-tai")
_findPointsOnSides(m, b)[source]

Looking for an intersection of a horizontal/vertical borders with a line equation does not neccessarily return a point within the range we’re looking for. It is easier and faster to do it manually. Each individual border will be checked manually and if it satisfies, two coordinates (defining a Point) will be appended to a list. Special cases of (0, 0) and (2048, 2048) will satisfy both border conditions and so will be duplicated in the result. Interestingly, if working from ‘frame’ reference system it’s not neccessary to know which reference frame we’re looking at.

  • m (float) – line slope
  • b (float) – line y intercept
classmethod query(condition=None)[source]

A class method that can be used to query the Event table. Appropriate for interactive work, not as appropriate for large codebase usage. See package help for more details on how the Session is kept open. Will return a query object, not the query result.

If condition is supplied it is interpreted as a common string SQL. It’s sufficient to use the names of mapped classes and their attributes as they will automatically be replaced by the correct table and column names.

Examples: Event.query().all() Event.query().first() Event.query(“run == 3”).all() Event.query(“Event.run > 3”).all() Event.query(“Frame.t > 4412911072y”).all() Event.query(“events.cx1 > 10000”).all() Event.query(“frames.filter == ‘i’”).all()


Snap the curent coordinates to the points of intersection of the reference frame CCD border and the linear feature.

A negatively sloped 45° linear feature passes diagonally across the first CCD in the array (1, ‘r’), cutting through both its corners. Such feature could be defined by P1(-1000, -1000) and P2(10000, 10000). Snap will determine the two border points P1(0,0) and P2(2048, 2048).