Eventmonitor

[g7gpr]

Added ability to define trajectory with single point and an az el

[dvida]

Thanks - I think there is a small conceptual issue. The AER (azimuth, elevation, range) function takes the azim and elev as specified, but we have to think about which range to take. Right now that's hardcoded to 1 m which will not generate useful trajectories. We should probably define azimuth, elevation and the fireball height. For example, if a single lat/lon/ht anchor point is given + azim/elev we should extend the trajectory up to the height of 100 km and down to 20 km.

[g7gpr]

The distance to the station uses the infinitely extended version of the trajectory, which is why R was arbitrary. For the FoV check, the trajectory needs to be extended, probably forwards and backwards.

[g7gpr]

Code now selects the start point on the trajectory and extends it forwards to the minimum luminous flight height, or the max luminous flight height for earth grazers, and backwards to the maximum luminous flight height. I've tested lots of edge cases - flight starting above or below limits, at limits, elevation at +90 and -90, and a few real trajectories.This is now running on a few stations in WA, and will be pushed out to all tomorrow.

[dvida]

Sounds good! I looked at the changes to AEH2Range - I think the assumption is that the elevation is always between 0 - 90 deg, it cannot be negative, otherwise the azimuth would have to be flipped by 180. Could you also properly indent the if block when beta is being computed and remove the debug print in the function? Also, when calling the function in EventMonitor, explicitly state that the keyword argument is accurate=True. I find that it's easier to add more keyword arguments later on when they're called explicitly, otherwise, things might break.

[g7gpr]

I can undo the changes to AEH2Range. They were only required when I was testing somewhat improbable edge cases, physically unlikely, but possible that a person could enter them as search parameters.

[dvida]

It's best to set the limits in the Event monitor, not the math function that is used by other operational scripts. Other than that, it looks good.

[g7gpr]

OK - I could not find any other uses, but I'll put it back exactly how it was.

[dvida]

Thanks! The function is used in AEH2LatLonAlt. I'll merge the PR now.

[g7gpr]

I don't think AEH2Range works for negative elevations - which is why I made those changes. I think it is OK looking up from a camera to a meteor, but looking down along a meteor trajectory, something is not working. I've got an idea on how to fix it without touching the existing libraries.

[dvida]

We should simply define a convention and make it clear in the file format. The fireball elevation is always measured from the bottom up, that's why we call earthrazers shallow entries for example. I don't think the elevation will cause a confusion as it's self-evident what it is regardless of how we look at it. We just have to figure out what to do with the azimuth. I suggest we set that as the direction of travel instead of the direction to the radiant.

[g7gpr]

Just to be clear, a descending fireball has a positive elevation?

[dvida]

Yes, that's the convention. There are never negative elevations. A shallow entry has an elevation below 20 deg and a steep entry close to 90 deg. We always look from the end of the fireball up, towards the radiant. With the azimuth though, we always make it clear what we're talking about, either the azimuth of the radiant or the azimuth of the flight direction.