With encouragement from Matt Hron, here is a potpourri of wishes for SMART desktop and Connect based on my experiences so far using Desktop 7.4. Perhaps some are resolved already and I’ve just not found solutions, and others are on a list somewhere.
Maps page
This was the single most baffling thing to me when I first opened SMART. The MAP doesn’t display any patrol data! It still seems hard to believe this isn’t the case.
Options for global satellite imagery background would be nice
Queries
Query that returns map for each unique patrol in the database
Query that generates a table of patrols showing their actual start and end times
Omit bank rows option in queries - critical if you include date and start hour in the query as the list of blanks is huge (possible in report with “is not null”, but this function is buried away and hard to figure out.
Reports
Format Data/Time in the Report doesn’t always work (e.g. for dates displayed from a Patrol Summary Query)
Allow a Compound Query (e.g. map) to be used in a report
Make it easier to see which query is being called when editing the components of a Report
The overlaying of layers in Report maps is opposite of how they appear in the list. The top item in the list is the bottom layer
Legend can easily obscure the data layers (observations, tracks) on a map in a report - can’t be controlled
Patrol Summary Query lacks sensible column names when imported to Report: e.g. Header_0 etc instead of PatrolID. If you edit the Alias and Display name when you bring in the data, it shows the Edited/Display name in the data field, but the Text header for the item remains as the unhelpful Header_0, so has to be edited again.
Queries and reports
On maps, allow display different symbols for different categories of feature. Only numerical variables can be used and only for colour ramps, not symbol styles, or colour palettes. e.g. logging, farming, mining observations could each have own symbol or coloured symbol. Colour ramp makes no sense for categories.
Allow setting default output folder for things like reports and queries
Patrols page
Allow filter the patrol list by leader
Allow option to display more columns of patrol info (leader, team, etc) in the patrol list
Database
Ability to export the database in a more widely usable format, not just xml which shows only hex keys that users can’t interpret, nor queries that lack essential elements of the database (like patrol start and stop times).
Things to help users track down Connect processing failures:
Allow bulk selection of packages (not clicking one by one) on Connect, and allow bulk actions - e.g. downloading, revising status (Complete, Queued etc)
More helpful file names for packages on Connect/JSONs, esp if downloaded. Can’t the names relate to “device + acquisition” time for example?
Make info within Desktop available regarding DeviceID, PatrolID, LeaderID etc so packages can be connected to patrols when tracing errors
Better info provided during package download to allow tracing of errors. Currently just says “track points 9 Jun 2022 matches multiple patrols… Ensure the patrol days and times do not overlap and try again.”. It doesn’t say which file this track point is in and if the item being processed has scrolled off the lower panel you can’t scroll down to see which it is
A way to cancel the processing queue that is in progress
A way to bulk select items in the queue to process, except selecting one by one. This is a nightmare if you happen to have a bunch of failed packages that you are hoping will come right in due course but want to avoid reprocessing each time.
A way to know if all packages from a patrol have been uploaded from a device, and to know if they have all been processed in Desktop from Connect. Download failures just sit on Connect and who knows what patrol they belong to. Patrol pages in SMART provides no clue if stuff is missing, except perhaps if the Stop patrol message hasn’t come through and then the end time is 23:59:59
Things that might help prevent Connect processing failures
Inclusion of PatrolID in trackpoint JSONs - device ID and date/time is not enough esp is a user starts and stops a patrol in less than 24 hours, or uploads new patrol before an earlier one has been successfully processed from the queue.
Process queue packages according to date/time of acquisition rather date/time of upload to server (or whatever order it is using at present), so that trackpoint files don’t arrive before the patrol stop message of the previous patrol.