Julie on 02 Apr, 2021 09:53 PM
I think some of the finer details will depend on the team needs, but I like to decide based on the mission. For example, if I am deploying 40 people via Chinook and they are all landing in one place then dispersing to their assignments, I do want the part of their track that shows them moving from the LZ to the start of the assignment because that is a valid search area still. On the other hand I do not want their helo flight on my map. This is reliant on team members, or at least team leaders, to remember to get their track going as soon as the airship leaves them, and we know there is a lot of room for human error.
I might consider a different method in other situations, for example if I have a large mapping team, then I might have everyone turn on their track during the briefing, and shut if off when they get back to debrief. Then the mapping team can do the tedious work of cleaning up the tracks. There are some major downsides to this method also, as you can imagine. For one thing, if you are in and area with cell service and everyone is recording to the map, it can be hard to view portions of the map. For example at Fordyce this week it was impossible to zoom on the IC on the map because there were so many tracks there. Plus all that track cleanup is just a big chore to tackle.
When someone opens the map with the QR code or from the team account, then starts recording a track, it defaults to recording to their account plus that map that is open. When they finish the track, it automatically converts from an app track to a line object on the same map. Once it converts to a line object, the truncate option disappears. Truncate will only eliminate the earlier part of the track. Thus it could be a reasonable workflow to have people start tracking from their homes (with the current mission map open and the track recording to that map), then after they check in at IC and deploy to the field, you truncate their track at that time.
One thing to keep in mind here is that you are only truncating the track that becomes a line on your map. The user's track keeps the full length. So the track saved to their account is still the full track, whether or not you truncated it on the map.
Finally, to chop off the end of the track after they leave the field, you still have to do that manually after it's converted to a line. If a user forgets to stop recording their track you can convert their app track to a line or track and then work with it as a line, even if they are still recording while driving or something.
Meghan and I are working on a SAR-specific training site that we hope to have out in the next 2-6 months. A lot of little things for the original training site have been put on hold so we can focus on building out the SAR training. Hopefully this answers some questions for you or at least gives you some ideas!
Thanks for taking the time for the detailed reply, it's definitely
helpful. Very much looking forward to the SAR training site.
As an observation, if I'm understanding, I'd hesitate to use Truncate Here
because you can't really tell from the map which is the early part of the
apptrack and which is the recent part, in this context where they start the
apptrack at home and leave it on until they get back home. I would hate to
nuke the wrong part accidentally, since there's no undo. I noticed there's
a 'convert to line' under the context menu of an apptrack, so maybe that's
the best way to go - is that basically equivalent to 'truncate here' at the
very first point of the apptrack?
We still do heavy training of Garmin GPS use for every search, as a part of
our academy and mission-ready requirements. We teach everyone to only
start recording when they begin their assignment, and to stop recording and
save with appropriate name when they end their assignment (unless the team
discusses and decides there's specific reason to do something different
like the case you describe). In this context, apptracks are a huge net
positive, beyond a doubt, but they do introduce some growing pains and
extra considerations into the question of what tracks to record and how to
make use of them.
Our top dog told everyone to always record and save everything no matter
what, from home to search to home all as one long continuous apptrack,
because we can, and because it's a safety benefit and a good tool to show
to DSW if someone gets in a car wreck on the way home or something. It's
kind of sounding like that directive was premature and not practical, is
that your impression too? I was thinking more along the lines of: everyone
start an apptack at home as soon as you decide to respond. This has been
handy to see who is enroute to the muster point and how long it might be
until they get there. Then when you get to the muster point, finish and
discard. Then start a new apptrack when you enter your assignment, and
finish and save it when you exit your assignment.
Honestly, I hope we will get to a point when we stop relying on Garmin
tracks and just rely on (finished and saved) apptracks. A few of us have
been talking about this on and off for a while. We haven't quite gotten to
the point of listing out the specific hurdles to be overcome before that
would happen, but, I could think of a handful right now (which you've
probably already thought of).
I guess the larger question is 'how do you get a good debrief map' that
shows the assignment boundary and just the tracks of the team that did that
assignment (and any markers they made) without the extra noise of
surrounding tracks, surrounding assignments, clues in other assignments,
tracks of different teams that entered the assignment, etc. I know that
ties in to the ownership model which will be going away (R.I.P. ownership
model - we definitely got a lot of utility out of it) but it's a
larger question. One point to consider is that each searcher who was
recording both Garmin tracks and apptracks looks like two searchers on the
map, giving a false impression of coverage, though it's an interesting
illustration of different GPS inaccuracies on different devices.
Sorry for the tome - any further advice you have on these good growing
pains will be much appreciated.
Julie on 07 Apr, 2021 03:15 PM
Convert to line takes whatever part of the track has been recorded so far and changes it to a line object in the lines and polygons folder. It's a good tool for after the user has finished the track, but if the user is still recording it may cause more confusion on your map. The track will keep recording and show up on the map again, but without a name. (You can try this by recording a track on your phone to a map that you are. watching on your computer.) Alternatively, you could copy it to a line while it's still recording and not run into that issue.
My teams typically do not use standalone GPS devices anymore. I think that's up for each team to figure out how they want to proceed, but SARTopo has built this tool with the idea that teams could use it in place of standalone GPS units, though there may be some missions where that is not always appropriate.
Managing tracks from searchers will always take time, regardless of the input type. It's certainly not a bad idea to have people recording from home. We have suggested that the live team tracking feature is one way to cover this sort of need. It doesn't provide a permanent record but does help with awareness of how close people are to responding. The idea to record a track from home, then stop it when arriving is a possibility. You could have a separate map for response and one for the mission data. This will be easier to manage when we have more account level folders available and you can group multiple maps from the same mission together.
One management idea is when people arrive at your IC, have them open the mission map as you are briefing them. Have them find their assignment on the mission map before they leave IC. This way you also make sure that they are opening the app to trigger them to stop their track coming from home, switch maps to the mission map, and be ready to go with recording their mission track.
As the mission grows and you have lots of responders, presumably you'll also have more people in IC who can help with managing the map and tracks. I'd divide the map into major sectors and assign map managers to each sector that has field teams working in it. I'd probably also create an event and put copies of the same map into the event with different names for each sector. Then the responders would open the map for the sector that their assignment is in and record to that map. Then each map manager for each sector has fewer tracks to deal with and they can copy them to lines and clean up the starts and finishes as necessary.
All this requires excellent briefing up front. I'm planning to develop some tools to help teams with that. We'll expand a lot more on this whole topic in the training site. Also when the dev team is able to get us nested map folder and tags, and account level folders and other features it will really expand how we manage search maps.
As for debrief maps - personally I would want to leave tracks on there from other teams that may have entered the area, as well as keep any tracks from outside the assignment. We think these assignment lines we draw on the map are so smart and useful, but mathematically they are totally arbitrary. The point is to get guidelines for where to search and to keep searchers safe, but the location of the MP has nothing to do with those lines. Tracks matter on the whole and not individually. Assignment boundaries are a useful organizing tool but not definitive for the location of the MP. I would skip the step of printing debrief maps and use the computer screen so you have a dynamic map that lets you turn objects on and off as necessary.
I should get back to writing things in the training site :) Hope this gives you some ideas to work with - it's not meant as a "you should do things this way" but as some things to think about.
Thanks, this is a lot of good info to chew on! I appreciate your taking
the time for this, I know it's larger than your average help ticket but
this is really getting to the meat of many of our questions of the past few
years, and with luck hopefully you'll find some of it to be useful feedback:
- copy to line instead of convert to line sounds like a win, we will try
- I don't think we've tried an Event - I'm reading up on Events at
training.caltopo.com now, thanks for the suggestion.
- hadn't thought of using a separate map for responses, and not having them
open the actual incident map until they get either to the muster point or
to the CP. Question: when does the map sync happen? If it doesn't happen
until they open the incident map on their phone, but they don't try to open
it until they are at the CP which may not have good cell service, how could
they go about getting the map?
- we will experiment with live team tracking / shared locations too.
- looking forward to the additional tools and docs you mention including
nested folders, tags, etc! Is there a way for us to get notified when any
of that goes live?
- not using Garmin - the promised land - how does your team approach the
question when there's no internet / cell coverage? This is one of the
things we had thought of as a hurdle to overcome before ditching Garmin:
transferring completed searcher tracks to CP computers as searchers return
from assignments but there is no cell service / no internet. There are
definitely options to get it done by exporting on the phone then
transferring the file by wire or wifi or bluetooth or such (automatic NFC
would win - searcher just places their phone on the NFC puck/plate and
their tracks automatically get imported - ahhhh...) but they are currently
less user friendly / require a bit of tech savvy / take a bit longer per
device that importing from Garmin. Do you know if there are any
development plans for the app to help with that process? Maybe mimic the
Garmin behavior by automatically exporting to a gpx file in a predictable
location on the phone as soon as you finish-and-save? Similar for
markers? That would make life a lot better. Going a bit further, thinking
out loud, I know there's no such thing as running a full-fledged server for
the caltopo app on our LAN, but maybe an export/import server with just
enough smarts to do the export and import operations as soon as a phone
running the app is connected to our wifi/bluetooth/NFC?
Also, dog handler Garmins are another hurdle, since they get GPS tracks
from the dog too - we have several of those on our team - is there a way
that the app can help there, like the app talking with their Garmin in the
field without needing internet, by wifi direct or bluetooth, to get both
the handler track and the dog track to be actual sartopo apptracks?
- debrief - I suppose it's more of a team philosophy issue, but there are
really two different debrief contexts: in the larger context of deciding
where to send the next teams, of course tracks from all teams should be
viewed, and that's done with command staff in front of the big screen; but
in the context of an individual team debrief, we definitely want to see
only that team's tracks. I know different teams have different debrief
workflows (for better or worse). In our debrief workflow, a debriefer sits
down with the team to go over their debrief form and their debrief map, to
ask about holes in coverage, discuss clues on the map, mark up the map and
file it with our official paperwork for both CYA and for next op planning,
etc. I see what you are saying, especially about the idea of paperless
debrief mapping, and we'll definitely incorporate it into our discussions
of how best to move forward.
I know in the past Matt had mentioned in passing - probably just as ideas -
future plans for some sort of association between an assignment and that
assignment's tracks/clues/markers, which would somewhat replace the
ownership model - do you know if anything is coming down the pipeline there
- is that maybe what the nested folders and tags thing was in reference
to? Or should we move forward assuming everything will stay flat and not
associated in any particular manner, in which case we might write some
python code to massage the geojson into separate team debrief maps.