Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

start time problem on data requests? #144

Open
kaspervanwijk opened this issue Feb 8, 2018 · 3 comments
Open

start time problem on data requests? #144

kaspervanwijk opened this issue Feb 8, 2018 · 3 comments

Comments

@kaspervanwijk
Copy link

Hi All,

Am I doing something wrong here? I am getting significant differences between requested start time and delivered start time. IRIS server does not have this problem. Simple code for one example where the difference is more than 6 seconds:

from obspy.clients.fdsn import Client
from obspy import UTCDateTime

geonetclient=Client('http://service.geonet.org.nz')

t0 = UTCDateTime("2015-02-27T06:30:00.000") 
st = geonetclient.get_waveforms("NZ","WIAZ","10","EHZ",t0,t0+10)
print('requested time {}, received starttime {} and difference {}'.format(t0, st[0].stats.starttime,t0-st[0].stats.starttime)
@rumachan
Copy link

rumachan commented Feb 9, 2018

Hi Kasper,
Isn't it just how the data buffers boundaries fall relative to your request? If you grab the same month/day/time for 2017, the difference is only 0.05s.

@kaspervanwijk
Copy link
Author

kaspervanwijk commented Feb 9, 2018 via email

@ozym
Copy link

ozym commented Feb 9, 2018

Hi Kasper,

What you are seeing with these queries is a difference between the IRIS implementation of the FDSN waveform service and that of GeoNet.

In both cases the raw data is stored in miniSEED format blocks in an archive. The IRIS mechanics is to gather all the raw blocks that would match a request, then repackage them together and, at this point, trim the edges of the recovered data to match the request. This trimmed set is what's returned.

GeoNet, on the otherhand, simply gathers together all the raw miniSEED blocks that contain "any" data that has been requested and will return these blocks unchanged. The benefit, from the service point of view, is that it is much more efficient and results in a quicker response -- as the data itself doesn't need to be unpacked and examined. Another benefit is that the data returned is exactly what is currently stored in the archive. This may be useful in terms of time corrections, or data consistency checks, which tend to be stored in the block headers and would need to be interpolated.

The downside, however, is that the user is then required to extract the time window themselves from the returned data (along the lines of what IRIS does). Whether this is tricky or not will depend on the application the data is being used for and the software. There are others who use ObsPy more than I do who would know a good way of doing this, but the obspy.core.stream.Stream.trim & obspy.core.trace.Trace.trim functions look handy.

Mark

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants