While this can be fixed by having the patrol team record a single point (e.g., a "Camp" position), if the team forgets to do this there is no way to add data for the blank day. WOuld this be fixed by the work being done ticket 718?

No, these would be considered different, but we should probably do them both at the same time.
#718

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?

Ideally this would be an option/check box: "Include days with no data in counts of patrol days" or similar.

The requirements for this are to:

• 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.

Image not found...

Image not found...

Any changes to the queries must be made on both the desktop and connect versions.

Implementation details need to be sorted out - if we remove rows from the data base for no data days or add a flag for filtering them or compute on the fly.

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...

Also updated connect queries and fixed some bugs I found related to area group bys.

@darrin when testing this can you also test the area group by options (group by patrol sector etc).

This change affects the "headers" of the summary queries which may also effect reports that use these queries. Reports may need to be refreshed and reconfigured in order to work correctly with these new names.

No issues encountered in version 6.0.a18

Bugs were found with this feature:

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.

Using update site v17, I am able to follow the instructions in the fix and get the appropriate results.

From Jonathan:

  The new query function (include/exclude says w no data) defaults to exclude, we want it to default to include as this is consistent with previous behavior

this seems to have been completed.