A few friends and I just completed the Baja XL and we used Gaia 1.7.1 on an iPad Mini for 95% of the nav. We also had a Garmin Zumo running the Deluxe mapset, and a laptop/tablet running a different set of satellite maps. Sat imagery really rules the day for this kind of nav, especially for a team of people. The sat maps available in Gaia Deluxe, from ESRI, are definitely several years old and it would have been nice to have fresher images.
Gaia isn't really set up to do an adventure rally. LeadNav seems to be the go-to app for that kind of thing but there is a higher cost of entry and I suspect a steeper learning curve. I settled on Gaia, figuring that we would just see what rose to the top out of the devices and apps that we had, and Gaia turned out to be it. This was probably as much for the ease of use of the iPad screen as anything else, but there are plenty of nav features in Gaia that came in handy. The Garmin had better line map data but using the screen is terrible compared to the iPad. The laptop/tablet had a great display but again not as easy as the iPad, and the app was not really a nav app. The iPad could be passed around the cabin easily and was super easy to interact with.
The biggest perceived weakness was that it does not route on roads when offline (it only routes on straight line segments), and we were offline pretty much all the time. It turned out to be not such a big deal, because many of the small tracks we were on were probably not routable anyway; the Garmin sure couldn't route on them. On the highways, though, it would have been nice to let Gaia provide the distances between cities so we could evaluate those options. Instead, we had to painstakingly create routes out of dozens of short segments that approximated the course of a particular route, be it dirt or highway. The only real workaround to this would be to create every viable route when online, and then save all of those routes in a folder in case you may need them later on.
It's a bit odd that you can't start or end a route at a waypoint. At least, you can't use a waypoint to define the beginning or end (or any part) of a route; tapping it will just expose WP info rather than set it as a route point. Instead, you have to zoom way in and then select a nearby point that specifically ISN'T the waypoint you want so that you can create a route. It would be SO nice to be able to simply ask for a route between WP1 and WP2, but WPs cannot be used that way.
I found the icons at the top (map layers, sidebar, create, follow) to be very hard to activate sometimes. I would tap and tap and tap and tap and sometimes it would work, sometimes it would work twice and I'd be back where I started, etc. I don't see how this can be an actual app problem but it was comically repetitive in our case. Every other screen element responded properly.
Gaia does not generally respect the text size setting in IOS. Change the setting, nothing in Gaia changes except some menu or submenu headings. Things that you actually have to read while actually using the app for navigation (like waypoint labels or track labels) would be good candidates for using this setting.
The map markup options are limited. You can create an area, but it's very hard to make anything but a triangle since the chord midpoints rarely can be moved. I wanted to add circles of a specified radius around WPs but could find no way to do that.
Other than the above, the basic functionality is pretty good so what follows is a description of how we used it for our event given what it would and wouldn't do.
To prepare for the event I downloaded ESRI sat imagery of the entire Baja peninsula at Z=17, which took well over 50 GB. This was really tedious because you have a 10,000 tile download limit on those. I had to make hundreds of downloads to do it all. One annoyance is that some of the files seem to be set up so that they are structured to a higher zoom level than the actual data. For instance, it seemed that if I downloaded to Z=17 but the data for a section only went to Z=16, I would get a Z=17 layer of gray tiles that just said "Map data not yet available." Let me tell you, it's a lot more useful to zoom into a blurry Z=16 real tile than it is to end up with a gray Z=17 tile that just says there is no data. This only happened in some places. It would be super helpful if the imagery ended at a zoom level that actually exists and you never end up having to zoom back out to see the actual imagery again. This is really important so I'm going to come up with a different way of saying it for anyone who didn't understand: zooming in and having the map disappear really sucks. It would be way better to just stay on the previous tile and have it get slightly blurry. This is not a Gaia app problem, it's a tileset problem, but they are provided by Gaia. Additionally there is the fact that we are potentially downloading gigabyes of tiles that don't have actual data in them.
In addition to the ESRI images I got Google Maps, Gaia topo, OSM traces, and regular OSM I think. They took up very little space compared to ESRI and typically had 100k tile limits per download, making them very quick.
It was a ten day event and I didn't want tracks and WPs from one day to clutter the screen for the next, so I created a folder for each day. This feature is great; you can turn folders on and off to show or hide everything in them. Imports go into a root folder and from there you can move items out into the subfolders. I created base routes for each day, as well as WPs that were in the roadbook for each day, and put them into the day folders. When the event started, each morning we were given a download of race WPs for the day, and they stayed in the root folder (along with all of the tracks I created during the day) and at the end of they day they all got moved into that day's folder, leaving a clean root for the next day.
On any given day, once we got the WPs, we would start to run options. We'd backtrack from the finish, calculating drop-dead times for reaching the finish on time from various places by road or by dirt. We'd calculate distances for various route options, assigning each segment a speed based on the sat imagery, to estimate how long it would take to get to a major midpoint of the overall route. I named each segment as its distance so I could just tap a track and see how long it was. There was never enough time to fully analyze the options, but we learned which data we were likely to need the most on a given day and then fine-tune it on the fly.
In motion, the navigator (whoever was holding the iPad) would be responsible for calling out turns to the driver as well as preparing him for upcoming problems. The app had a small lag between the position shown on the map and the actual position, which we had to get used to. Typical directions to the driver sounded like, "200 yards then half-right... just past the half right there's probably a wash... after this crest, hard left... OK coming up to another wash... if the road splits, keep right..." etc. This was all pretty easy to see with the arrow moving on the sat map, although we all knew the imagery was dated.
We had timed-distance challenges too, for which we used the "Record track" function. That way we had average speed, elapsed time, etc. I think Gaia will only record one track, so if we were already recording the day's route we had to stop that and start a new one for the timed section.
That's about it. If I had it to do over again I think I would still use it. Any questions, post 'em.
