[Realtime-feed-users] Delayed feeds and/or events (1+ hours)

[David Loring]

Hi Jeremy,

 

I build my data from the 7 day feeds with an occasional 30 day thrown in to catch changes, but I do use the I hour for Mag 6 events and have had I think only one problem with latency in the past.

 

I don’t know if Matt is building a catalogue with the data but I certainly would agree that for that context the longer timed feeds are more appropriate.

 

Regards

David

 

From: Fee, Jeremy [mailto:jmfee at usgs.gov] 
Sent: 14 July 2014 20:26
To: realtime-feed-users at geohazards.usgs.gov
Cc: Matt Keller; Harold Lemon; David Loring
Subject: Re: [Realtime-feed-users] Delayed feeds and/or events (1+ hours)

 

Hello,

 

Some of the "lag" is from the time it takes for seismic waves to propagate.  Some is due to network reporting thresholds.  Small, dense networks issue automatic solutions for local events within seconds or minutes after an event.  NEIC only issues reviewed solutions, typically 15 minutes after an event to give time for enough station data to arrive.  As analysts further review seismic data, new events may be located and existing events updated or removed.

 

Realtime feeds and the Catalog web service provide snapshots of contributed data, but it is important to keep in mind that the underlying data is changing as these review processes continue.  Our latest earthquake and event page applications display the current contents of feeds and search results ( http://earthquake.usgs.gov/earthquakes/map/ ).

 

If you are trying to build a catalog based on feed snapshots, it is simpler to run our catalog software locally (or use our catalog web service).  PDL can be downloaded from http://ehppdl1.cr.usgs.gov/ , and several examples are available on github at https://github.com/jmfee-usgs/pdl-client-examples .  PDL also triggers configurable processing as data arrives and/or events are updated.

 

 

Thanks,

 

Jeremy

 

 

On Sat, Jul 12, 2014 at 4:35 AM, David Loring <dloring at eircom.net> wrote:

Thinking about it the provision of, or changing to, a 2 hour file would resolve virtually all lags. Probably worth considering.

 

 

From: Realtime-feed-users [mailto:realtime-feed-users-bounces at geohazards.usgs.gov] On Behalf Of David Loring
Sent: 12 July 2014 11:09
To: 'Matt Keller'; 'Harold Lemon'


Cc: realtime-feed-users at geohazards.usgs.gov
Subject: Re: [Realtime-feed-users] Delayed feeds and/or events (1+ hours)

 

For example, if the event occurs at 1pm, and is posted at 1:30pm, the event would fall off the feed at 2pm thus only staying on the feed for 30 minutes.

 

Yup, exactly what happens. This should not be a problem if you are accessing every 5 minutes Matt, except where a quake does not make it to the short list inside one hour as does happen.

 

David

 

From: Realtime-feed-users [mailto:realtime-feed-users-bounces at geohazards.usgs.gov] On Behalf Of Matt Keller
Sent: 12 July 2014 01:18
To: Harold Lemon
Cc: realtime-feed-users at geohazards.usgs.gov
Subject: Re: [Realtime-feed-users] Delayed feeds and/or events (1+ hours)

 

Harold, 

I'm glad to know I'm not the only one experiencing this issue. With regard to events not staying on the feed for an hour, I always assumed that the "Past Hour" meant that it only showed events that actually occurred within the last hour. For example, if the event occurs at 1pm, and is posted at 1:30pm, the event would fall off the feed at 2pm thus only staying on the feed for 30 minutes. I think this is why my app was missing so many events. The event would be posted 1+ hours after it occurred so it was only hitting the Past Day and longer feeds. Though i could be wrong. 


_______________________________________________
Realtime-feed-users mailing list
Realtime-feed-users at geohazards.usgs.gov
https://geohazards.usgs.gov/mailman/listinfo/realtime-feed-users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/realtime-feed-users/attachments/20140714/48ae85ac/attachment-0001.html>