### Find possible stellar occultations by a given asteroid

Assume the orbit of an asteroid is pre-calculated by an external function, and further assume that this orbit, as a collection of (RA,DEC) points is put into a variable @orbit, of geometry type "LineString". The query itself is then trivial, but the load is extreme.

```SELECT o.ra, o.decl
FROM MovingObject o
WHERE Distance(o.position,orbit) < :distance
```

Function Distance(g1,g2) returns the smallest distance between any points in two geometries.

-- -LJ This would be a stretch to support in DC3b.

We would have an orbit in movingObject - q/e/i/node/argperi/timeperi + errors - which could be input into an ephemeris generator, which would then predict the position of the movingobject at a string of times, along with the error in the position of the movingobject. All of these positions (and their errors) would then have to be matched against the Object (not movingObject) table to see if they come within a certain distance of a star (need the classification flag for star vs. galaxy) brighter than X mags - and those distances need to include the errors. So perhaps distance(o.position, ephemeris) < givenDistance + error (where error = error in o.position + error in ephemeris, added in quadrature).

We have code which can do step 1 here, and the select for part 2 shouldn't be so bad, but figuring out how to handle the input and limit the query could be tough.

Presumably the user would also need to specify how brighter the background star would have to be, where their observatory was located (this might make a difference at the level of a stellar occulation) for the ephemeris generation, and some limits on the error in the distance between the movingObject and the Star they are willing to tolerate.

The time step between ephemeris calculations would also have to be either given by the user or calculated by the function: this time step could be arbitrarily small if a user wanted to have a very small error on the position for a fast-moving object, or it could be rather large if a user was willing to tolerate a large error in the distance matching or was looking for occultations by a very slow-moving object.

The error in the ephemeris will grow with time, increasing the number of matches. The number of ephemeride points to match against the Object table will also grow with time.

Along with some of the other problems above, the error in the ephemerides and the length of time that the user wants to check for stellar occultations over, this could lead to a pretty heavy computational burden.