[DOCS] Add tutorial for using local data

[calum-chamberlain]

Is your feature request related to a problem? Please describe.
The docs outline the Tribe.client_detect method, but not the Tribe.detect method. These are really similar, but enough people ask me about this that there definitely should be an obvious example for how to use your own data.

Describe the solution you'd like
A tutorial for "using your own data". Similar to the main matched-filter tutorial, but starting off with some data. These data can just be downloaded from an FDSN service. This would need to be run as a test as well, probably just on cricleci along with the others.

Describe alternatives you've considered
Nada.

Additional context
This would be a great issue for someone to tackle to contribute to EQcorrscan.

[tjnewton]

Hey @calum-chamberlain , I am using EQcorrscan on some local files and I think it will be a good start for this tutorial. I'm working through the process now but I'm getting an error at the detection step. I ran in DEBUG mode but it's still not clear to me what's going wrong. This occurs in cell 5 of the notebook linked below. Any idea what's going on here?

Notebook and data here

[calum-chamberlain]

Ah, that is my bad - return_stream isn't doing anything for that call (it isn't a defined argument, but is accepted without error as it gets caught in kwargs), so the call to Tribe.detect is only returning the party and not st.

Sorry about that - the options for making this clearer as far as I have thought of are:

1. Actually use return_st (and all other optional arguments for client_detect to have a consistent API between them)
2. Catch and error if unknown args are provided
3. Leave as is...

Option 1 isn't great from a memory efficiency standpoint: in client_detect return_st returns the unprocessed stream - to do this it has to make a copy of the stream before processing it internally, which would effectively duplicate memory for detect. Totally possible though, and also possible to return the processed stream, which would be useful for reducing duplicate processing for lag_calc if you were to use it...

Option 2 is the simplest at face value, but the main reason for coping with *args and **kwargs is to pass those through to lower functions, without having to duplicate args throughout the API...

Option 3 is fine, but it requires people to know that the error ValueError: not enough values to unpack (expected 2, got 1) corresponds to the returned value, and it is not very clear!

I'm leaning towards option 1 just for consistency, and I think it would probably be easier for users, even if it is a bit more work for me!

Also, yes please a local data tutorial would be awesome! Happy to provide any help needed.

[tjnewton]

I don't need the stream anyway so simply removing the st did the trick! Thanks for the thorough description. I'll tidy this up once I'm finished with it and create a pull request for the local data tutorial.