Tweet_trigger check for tweeting events close in space and time

[mguy-usgs]

We need to evaluate the logic in tweet_trigger that checks for events that are too close in space and time, because in the following case a 5.2 did not get tweeted, but the earlier 3.1 did

tweet_trigger.log 2018-06-29 12:16:25 INFO - Ignoring event 'hv70339416', close in time and location to already tweeted event hv70339386. Exiting

the 70339416 was a 5.2 and a very different quake than the earlier 3.1, so should we check mag differences too? Like if the magnitudes of the two close in space and time quakes is different by 0.5 or more, then still tweet the event? This is for the case where the event has another event ID, maybe and we add a check on different event ID from same source (e.g. here both from HV, they are saying they are different quakes...). The original thinking was in an aftershock sequence we don't want to flood followers (tweet consumers) with tweets, but here we actually wanted to tweet about both! Additionally, the check to see if we ever tweeted the event before is independent of twitter account type (e.g. a test account could tweet a 3.1 and then a 5.5 comes in event the siginificant account would check if any tweet was sent, but the significant account did not sent the tweet, the test account did before, so there is no overlap for the siginificant account).

https://earthquake.usgs.gov/earthquakes/eventpage/hv70339416#executive https://earthquake.usgs.gov/earthquakes/eventpage/hv70339386#executive

Check 4: tweet has not already been sent for another event which is

# close in time and space to this event
tooclosedistance = config.get('SETUP', 'tooclosedistance')
toooldtime = config.get('SETUP', 'toooldtime')
latlondiff = format((int(tooclosedistance)/111), '.1f')
eventtime = etime[:8] + 'T' + etime[8:]

query = ("select event_id from tweet_audit where (event_time <= (timestamp'{0}' + interval "
         "'{1}' minute) and event_time >= (timestamp'{2}' - interval '{3}' minute)) and "
         "abs(event_lat - {4}) <= {5} and abs(event_lon - {6}) <= {7}")
query = query.format(eventtime, toooldtime, eventtime, toooldtime, lat, str(latlondiff),
                     lon, str(latlondiff))
longquery = query + " union select NULL where not exists (" + query + ");"
cur.execute(longquery)
tweetmatch = cur.fetchone()[0]

if tweetmatch is not None:
    info_string = """Ignoring event '%s', close in time and location to already tweeted 
                  event %s. Exiting""" % (
                  eid,
                  tweetmatch)
    logger.info(info_string)
    return False

[mguy-usgs]

I think additional logic should be added IF there is a match on close in space and time e.g. if match found for close in space and time, then check if matching event magnitudes differ by more than 1 magnitude unit and that the event ID's are not the same (meaning another event occurrent) then still tweet the event (e.g if (absoluteValue(mag1 - mag2) > 1.0 and eventID1 != eventID2) then still tweet)

[paulearle]

Actually, this can be problematic because usually when different ID are issued for an event it is an indication that something is wrong. And often when something is wrong the mag is also wrong. Big variations can happen when the mag type is changed (for example). I would keep it as it has been running for several years. I agree it could cause a problem but so far it has been better to keep it as we have it.