Outline and Clarify UI/UX

[bmotevalli]

The aim of this task is to clarify the user flows / user interactions.

[bmotevalli]

Questions:

• days_per_request: is this a setting parameter? should it go to the settings page?

• force_stations and exclude_stations: they actually have two info: network and station. Probably we'll split it at UI level (ie., at UI we’ll get this info separately, then concat them before passing to the main script or we’ll provide a free input text that users will provide the input in one go.)

• In [Event] section of .cfg file, there are two set of radius parameters:

• minsearchradius, maxsearchradius -> this seems to be the actual search radius to locate events
• minradius, maxradius -> not quite sure what is this for. From your description it looks it probably is a search radius around selected stations. Is this correct? or is it actually the other way around, i.e., for each event that is found, it will use minradius and maxradius to locate the stations around the event? We would need to understand how the user interaction and user flow would be at UI level for this feature.

• In [STATION] block: it seems there are a couple of different ways to define the search:

• inventory -> it would be helpful to know how this option works? what type of files it expects? if we want to offer this option to user, how this should be defined at UI level?
• map search -> definition of box or circles on map
• manual entry of n,s,l,c -> how user should provide these values? as free text inputs or in a form of controlled values via dropdowns?
• It looks the script runs on above order (it wouldn't do all together if all above are defined). Is that what is expected? If so, we might need some way to make this clear to the users, e.g., give them only one of these options at a time.

• There seems there are inconsistent naming for values of search_type and geo_constraint but it looks their intend is the same

• List of geometry contraints: we are assuming user will be able to select multiple list of search areas (we can demo in the next meeting).

• Issue with example_continuous.cfg: when running the script with this input, we get following error: ValueError: The FDSN service shortcut EARTHSCOPE is unknown. I did not find this client in the list of obspy docs.

• Not exactly understanding "inv" in collect_requests_event(eq,inv,...) in the EVENT block: "inv" input is from STATION block, which has its own searching parameters separate from EVENT. It looks like for each event we are looking into "inv" to identify which of the stations fall in the minradius, maxradius. Now, please see following questions:

• What if the searching parameters (e.g. location or time) is completely different to the EVENTS? If there should be consistency between these two blocks, why two set of different searching parameters are defined?
• Is the above function designed to get timeseries of an event from a close by station? If this is the case, maybe it would be better to handle this in a multi-step fashion:  step 1: only get events and show to users (only requires EVENT block definition)  step 2: user selects a set of events -> sets min,max radius and time intervals  step 3: for each event, we find the stations (i.e. inv) and collect the queries.
• Note: if above approach makes sense, then the [STATION] block can be used only for continuous data.

• Datetimes: At the UI level, we are only accepting Dates (not datetime) for the filters. Is it crucial to consider time as well for start and end times?

[filefolder]

• days_per_request: is this a setting parameter? should it go to the settings page?

right now it is under waveform. I think this is correct as this only affects dataselect behaviour. dictates how large each request should be.

• force_stations and exclude_stations: they actually have two info: network and station. Probably we'll split it at UI level (ie., at UI we’ll get this info separately, then concat them before passing to the main script or we’ll provide a free input text that users will provide the input in one go.)

yes. since network and station are always used together, both in station and dataselect, it will probably make sense to keep them bundled up as one object until the relative calls require them to be split.

• In [Event] section of .cfg file, there are two set of radius parameters:

* minsearchradius, maxsearchradius -> this seems to be the actual search radius to locate events

* minradius, maxradius -> not quite sure what is this for. From your description it looks it probably is a search radius around selected stations. Is this correct? or is it actually the other way around, i.e., for each event that is found, it will use minradius and maxradius to locate the stations around the event? We would need to understand how the user interaction and user flow would be at UI level for this feature.

yes, there is one for event and one for station. I think minsearchradius implies event, whereas minradius is for station. There is no particular for this as they are catagories of [EVENT] and [STATION]so could be named the same.

• In [STATION] block: it seems there are a couple of different ways to define the search:

radius (or "donut") and square only. that usually suffices.

* inventory -> it would be helpful to know how this option works? what type of files it expects? if we want to offer this option to user, how this should be defined at UI level?

Good question and I will upload an example. The idea here is that a user already knows what stations they want and have saved them as a STATIONXML file (e.g. what you download from AusPass with output=FDSN station XML). This is probably pretty common. So essentially we are skipping the search, which downloads this XML file, and just use a user's saved XML file directly.

* map search -> definition of box or circles on map

* manual entry of n,s,l,c -> how user should provide these values? as free text inputs or in a form of controlled values via dropdowns?

free text seems more elegant. One simple field e.g. "XX.STA01..BHZ" for network = XX, station='STA01', location='',channel='BHZ'

* It looks the script runs on above order (it wouldn't do all together if all above are defined). Is that what is expected? If so, we might need some way to make this clear to the users, e.g., give them only one of these options at a time.

I don't quite understand...

• There seems there are inconsistent naming for values of search_type and geo_constraint but it looks their intend is the same

yes, good catch. they should both be geo_constraint to follow the FDSN specification

• List of geometry contraints: we are assuming user will be able to select multiple list of search areas (we can demo in the next meeting).

OK, it doesn't need to be too fancy, circle or square. The only special thing would be the option to manually draw it rather than enter numbers.

• Issue with example_continuous.cfg: when running the script with this input, we get following error: ValueError: The FDSN service shortcut EARTHSCOPE is unknown. I did not find this client in the list of obspy docs.

short version of the solution is: require obspy>=1.4.1

• Not exactly understanding "inv" in collect_requests_event(eq,inv,...) in the EVENT block: "inv" input is from STATION block, which has its own searching parameters separate from EVENT. It looks like for each event we are looking into "inv" to identify which of the stations fall in the minradius, maxradius. Now, please see following questions:

inv is the defacto variable name for FDSN station data (loaded from an xml, or downloaded via get_stations) st is the defacto for "waveform stream".. tr for trace, one array element of st cat for "event catalog"

* What if the searching parameters (e.g. location or time) is completely different to the EVENTS? If there should be consistency between these two blocks, why two set of different searching parameters are defined?

They will almost always be different. You typically want stations in one place, and events between 30 and 90 degrees from these stations. The way this is currently handled is by separating the parameter categories

* Is the above function designed to get timeseries of an event from a close by station? If this is the case, maybe it would be better to handle this in a multi-step fashion:
     step 1: only get events and show to users (only requires EVENT block definition)
     step 2: user selects a set of events -> sets min,max radius and time intervals
     step 3: for each event, we find the stations (i.e. inv) and collect the queries.

* Note: if above approach makes sense, then the [STATION] block can be used only for continuous data.

you will definitely need [STATION] for event.cfg as well, but the parameters will be the same. Perhaps I don't understand the question all the way.

• Datetimes: At the UI level, we are only accepting Dates (not datetime) for the filters. Is it crucial to consider time as well for start and end times?

97% of the time the date level should be fine for searches, but there are use cases for intraday searches also. So it may be good to keep time as datetime objects to allow detail when required.

Dates and times are tricky here. Obspy has its own format (UTCDateTime) that is mostly compatible with a datetime object but it's not quite identical. At some point they are going to port it over to use actual datetime objects but this code should stick with UTCDateTime calls whenever interfacing with Obspy items. Format is year, month,day, hour, min, second (integer), microsecond (integer).