Allow non-contiguous Patrol dates for both single and multi-leg patrols
"There are situations where a multi-day patrol may not actually go on patrol for each day of the patrol (e.g., in cases where there is heavy rain one day). It woudl be preferable not to have to have the requirement for patrol days on every day of a multi-day patrol."
Leave a comment
RRI Discussion:
I gather this is a problem with CT data; in case where patrol records data on day 1 and day 3 and not day 2. We can fix the CT import to import this without an error (maybe show a warning). But the SMART UI would still have a “day editor” for day 2 (with no observations).
Should these “non patrol” days be included in queries?
I gather this is a problem with CT data; in case where patrol records data on day 1 and day 3 and not day 2. We can fix the CT import to import this without an error (maybe show a warning). But the SMART UI would still have a “day editor” for day 2 (with no observations).
Should these “non patrol” days be included in queries?
The requirements for this are to:
For patrol summary queries this is going to affect the following summary values:
For a day to be classified as a "no data" day it would have no track and no waypoints. So if the user created a day, configured the start and end time and rest minutes for that day but didn't upload any track or waypoints it would be considered a "No Data" day.
If multiple legs occur for a day all legs would have to have no data.
- hide day tabs in the patrol editor that have no data in them [but allow users to add data to them]
- not count these days in patrol summary queries [or at least provide an option]
For patrol summary queries this is going to affect the following summary values:
- Number of Days
- Number of Nights (which is computed as number of days - 1)
- Number of Active Patrol Hours
- Number of Patrol Hours
- Person - Field Hours
- Person - Days
For a day to be classified as a "no data" day it would have no track and no waypoints. So if the user created a day, configured the start and end time and rest minutes for that day but didn't upload any track or waypoints it would be considered a "No Data" day.
If multiple legs occur for a day all legs would have to have no data.
We could potentially add this check for empty days into the list of QA checks from #784, thereby reusing the interface of selecting whether to run it automatically or not on new data being imported into the system. I suppose this depends on the implementation. If we are only calculating things on the fly, maybe there is nothing to do at load-time.
Slightly modified from original suggestions:
On the patrol editor there is a new column that says "Yes" or "No" if a patrol leg day has data in it or not. A patrol leg day is determined to have data if here is at least one waypoint or a track defined for that leg day. If not, then it has no data, irregardless of if the start time/end time/rest minutes are specified.
A patrol day is considered to have data if at least one leg-day has data for that day.
All days are shown as tabs in the editor. Days without data are in italics (with a tooltip).
Image not found...
For the query options ( Number of Days, Number of Nights (which is computed as number of days - 1 per patrol), Number of Active Patrol Hours, Number of Patrol Hours, Person - Field Hours,Person - Days) users are given an option exclude no data days. All previous queries will not have this option checked. If checked then days with no data will not be counted in the query results. For ratios the option applies to both the numerator and denominator.
Image not found...
On the patrol editor there is a new column that says "Yes" or "No" if a patrol leg day has data in it or not. A patrol leg day is determined to have data if here is at least one waypoint or a track defined for that leg day. If not, then it has no data, irregardless of if the start time/end time/rest minutes are specified.
A patrol day is considered to have data if at least one leg-day has data for that day.
All days are shown as tabs in the editor. Days without data are in italics (with a tooltip).
Image not found...
For the query options ( Number of Days, Number of Nights (which is computed as number of days - 1 per patrol), Number of Active Patrol Hours, Number of Patrol Hours, Person - Field Hours,Person - Days) users are given an option exclude no data days. All previous queries will not have this option checked. If checked then days with no data will not be counted in the query results. For ratios the option applies to both the numerator and denominator.
Image not found...
Bugs were found with this feature:
Image not found...
Two issues with this
* If you select the option then the changes are not retained on saving the query
* IN the reports, it defaults to calculating patrol days with no-data days excluded every time (whether you select that option or not)
See attached when running the report (no data days automatically excluded even if this option is not selected), and the correct result when running the same query in the Query window (also with option to exclude days not selected).
Image not found...
The save behavior with the “Exclude days with no data” option seems to be unpredictable. I have instances where checking it doesn’t save, unchecking it doesn’t save and where the opposite of what is done saves (e.g., I checked it on one value, unchecked it on two others, saved and closed the query, then on reopening, the opposite settings were retained). If you have a query where the option is unchecked for all values, then use Save as…, the resultant query will have all the values with the box checked, and vice versa. Basically, I think it is saving the opposite of whatever checkbox settings you choose.
By playing around with the checkboxes like this it is possible to get both the checked and unchecked values to save (make edits and choose the opposite of what you want). Once you do this the results do change in the reports (below), but the column headers and values are the opposite of what the query settings are. In the example below, the query the first table is based on does NOT exclude no data, and the second one DOES. The queries themselves produce the correct results, but the opposite is displayed in the report.
Changing the checkbox and saving the query breaks the report after you update query bindings. If you return the query to the settings that were present when the report was create/data source was added and update bindings again the report works again.
This is a serious issue. Number of days, hours, etc is a major metric used by a huge number of sites. There is no workaround that I can figure out.
The checkbox fix is included in SMART 6 update site v17 (and later). We have new desktop builds for this too (SMART.6.2.3.RC17)
NOTE: If you change the query checkbox option, any reports that use that query will become invalid and have to be edited manually. Rebinding query columns does not fix this as the Column names are now different - the report has to be edited manually.
NOTE: If you change the query checkbox option, any reports that use that query will become invalid and have to be edited manually. Rebinding query columns does not fix this as the Column names are now different - the report has to be edited manually.