Update Release Tag

See merge request !343

Network Parameter Addition

See merge request !342

Added a network paramter to all list of Observatories and Variometers. I made this a non optional paramter within Observatory.py.

Fix _post_process() in FDSNFactory

See merge request !341

The FDSNFactory was not working with input streams that contained multiple
segments. This was because FDSNFactory wasn't doing the full "_post_process"
like, for example, EdgeFactory. More specifically, FDSNFactory's `_post_process()`
method did not convert masked arrays (which is how obspy prefers to deal with
gappy data) into regular numpy arrays with NaNs for missing data, as expected
in all geomag-algorithms code.

This became quickly obvious once some of the less stable ASL variometers
were processed, like US-EYMN. This fix should allow us to now pull and plot
EYMN, DGMT, and other stations that were not working with the previous
release of FDSNFactory.

Adding a few changes to FDSNFActory regarding the FDSNNoDataException. I also...

See merge request !340

Updated data_test.py to not retrieve FilterApiQuery from DataApiQuery. Honestly not sure how these are just now causing issues when all my previous commits have contained this code.

I removed an unecessary call to FilterApiQuery from within Data.py. I also added validation to the FilterApiQuery.py. Rather than using super I opted to add the validation to this file beacuse sampling_period was ignored from the base class i.e. DataApiQuery and this is why the REQUEST_LIMIT was being ignored.

Adding a few changes to FDSNFActory regarding the FDSNNoDataException. I also created a private function to contain the logic that removes sensitivity/response info for traces. I added all avaiable stations that transmit geomgagnetic data for networks, IU, N4, and US to the VariometerMetadata.py module.

204 Error Exception Handling

See merge request !339

Function get_nearest_time() behaves as expected now

See merge request !338

The previous unit test relied on broken behavior of get_nearest_time()
to pass. With get_nearest_time() fixed, the unit test needed to be
updated accordingly.

A FilterAlgorith.py module function get_nearest_time() is supposed to return
the nearest *allowed* time for a given filter "step". This worked fine with
steps for second and minute data, whose allowed times are the tops of seconds
and minutes. However, for hourly (and daily, and any "average" type step),
things failed since the allowed times are the center of the interval (for
example, for hourly data, which is the average of all minute samples from
00 to 59, the the allowed time is 29:30).

One consequence was that if a user specified an interval with a start and
end time that did not encompass a given hour's allowed center time (e.g.,
start=AA:29:31, end=BB:29:29), the algorithm would still return a sample
for time BB:29:30. More generally, requests for average type data would
include an extra sample.

In this fixed version, if start=AA:29:31, and end=BB:29:29, nothing is
returned, as intended (and as always worked for non-average type steps).
Furthermoref start=AA:29:30, and end=BB:29:29, a sample for hour AA is
generated; if start=AA:29:31, and end=BB:29:30, a sample for hour BB is
generated, and if start=AA:29:30, and end=BB:29:30, samples for both AA
and BB are generated, all as intended.

Remove Instrument Sensitivity/Response

See merge request !337

Added previous changes Josh made regarding the removal of the instruments response/sensitivity. I also added some default innit function incase the user wants to override this logic as requested in the original issue.

 Added logic to determine when to use the remove_sensitivity or remove_response function on trace objects. I alsoadded a remove_sensitivity flag to the __init__ function so that a user can override the default value of None fo instances where they want to use a specifc function and ignore the default logic.

FDSN 3D Rotation

See merge request !335

Remove instrument_sensitivity if it exist. If it doesn't exist, then
an instrument_polynomial must describe the response, which is how the
Geomagnetism Program specifies an offset and gain response. We do not
attempt to remove any frequency-depenent response since these all seem
tailored to seismic data (e.g., no DC/zero-frequency response).

Added necessary check within FDSNSNCL.py to assign the sncl.channel as LF1,LF2,LFZ when X,Y,Z are requested by the user.

REsolved comments made by Josh. The rotation function is now sampling frequency agnostic, while also relying on the original stream created under get_timeseries.

Removed previous lines of code that checked metadata for Azimuth and Dip and replaced it with a new function that rotates the Stream object if channels X, Y, or Z, are requested and returns the appropriate channel after rotation.

Fix FilterAlgorithm.align_trace() method and unit tests

See merge request !336

The method FilterAlgorithm.align_trace() pre-processes the `trace.data` input
array for subsequent processing by FilterAlgorithm.firfilter() such that the
first input array element corresponds to a time step on which output samples
must fall (as defined in the dictionary `step`) minus half the fir window
width. In short, it ensures that output samples fall on desired time steps.

Prior to this fix, it only worked as intended when input trace's starttime fell
on an even time step. A bug became obvious when attempting to filter data from
non-Geomag stations that did not have nice time stamps. This fix addresses that
issue, and also ensures that `align_trace()` does what was claimed in its own
original docstrings, which is to handle trailing misalignments as well.

Note: one thing `align_trace()` does NOT do is ensure that all needed input
data are available to generate desired outputs. The user is responsible for
providing this, but can use the FilterAlgorithm.get_input_interal() method
to calculate the actual required input starttime and endtime. The method
`align_trace()` will trim or pad with NaNs only enough to align time stamps,
and may actually result in `firfilter()` output that are NaNs if the input
trace was not adequate.

Trying a better "rebase" (https://stackoverflow.com/a/71982894)

Changes to AdjustedAlgorithm and AdjustedMatrix classes (and unit tests)

See merge request !328

It was necessary to explicitly set inchannels and outchannels when
instantiating the AdjustedAlgorithm class in unit tests after other
changes in this MR were made to remove the hard-coded default
inchannels and outchannels.

- no longer forces default inchannels and outchannels, and lets the
  AdjustedMatrix.process() method "do the right thing" if neither is
  explicitly set by the user
- some mostly aesthetic changes that more cleanly separate the vector
  and scalar (F) adjustements
- modified AdjustedAlgorithm.can_produce_data():
  a. if any non-F inchannels cannot produce data, return False
  b. if F inchannel can produce data, return True as long as all
     non-F inchannels can also produce data
  c. if this is not desirable (e.g., you want to treat non-F and F
     channels independently), it is necessary to create two instances
     of AdjustedAlgorithm, one for non-F inchannels, and one for F.

- explicitly setting inchannels and outchannels is now optional,
  and default values are pulled from the input stream argument
  of AdjustedMatrix.process() method
- *if* non-F inchannels and outchannels are specified, they are
  checked for dimensional consistency with each other, and with
  self.matrix
- returns dimensionally consistent array of NaNs if there is any
  mismatch in inchannels, outchannels, or self.matrix
- raises exception only if all inchannels are not provided in
  the input stream
- requires F be specified in both inchannels and outchannels, or
  else it returns NaNs for F

This sounds a little complicated, and it is, but it was necessary
in order to allow the AdjustedMatrix class to adjust both vector
values (e.g., HEZ->XYZ), as well as scalar F values (e.g., pier
corrections). An argument could be made to separate these, but I
am not willing to do so at the moment.