Rosa Sala
Why GPS Audio Commentary for Sightseeing Vehicles Fails: And How to Fix It
If you operate a sightseeing boat, a hop-on hop-off bus, or a tourist train, you have probably already decided that a smartphone-based audio guide is the right direction. No hardware to distribute, no apps to download, no PA system blasting the same sentence in six languages while passengers quietly contemplate jumping overboard.
But once you start looking seriously at providers, you run into a technical question that nobody seems to answer cleanly: how do you trigger audio commentary automatically, at the right moment, without relying on GPS permissions that passengers may never grant correctly?
This article explains why that question is harder than it looks, why most current solutions are workarounds rather than real answers, and what a proper solution actually involves.
The Problem with Loudspeakers (Yes, We Need to Say It)
The traditional approach to multilingual commentary on sightseeing vehicles is the PA system, or tannoy as it is still called in British English. It works, in the sense that sound comes out of it. But it imposes a single experience on everyone aboard, at a volume they did not choose, in a language that may not be theirs.
The multilingual version is worse. Anyone who has taken a river cruise in a popular European city will recognise the experience: "What you can see on your left is the old cathedral." Pause. "Was Sie hier links sehen können, ist die alte Kathedrale." Pause. "Lo que pueden ver a su izquierda es la antigua catedral." And so on, through five or six languages, by which point the cathedral has long disappeared behind you.
There is also a passenger segment that operators rarely think about: locals. City residents could enjoy their own waterways at the weekend, sitting with a beer on board and enjoying the view with friends. A noisy tannoy system telling them things they already know ruins the magic of the sunset and drives them away.
And there is a dimension that rarely surfaces in operator discussions: accessibility. A passenger who used a Nubart-powered guide on one of our partner vessels wrote this in our feedback form at the end of the guide:
For some passengers, opt-in audio is the difference between joining the tour and staying home. This includes passengers with sensory processing sensitivities, but also those who use Bluetooth hearing aids, which can stream audio directly from their smartphone without any additional hardware or setup. A PA system cannot do that.
Why Native Apps Are the Wrong Answer
The obvious alternative to a PA system is a native app. Several providers offer them, and they do solve some technical problems, particularly around background GPS and offline capability.
But for sightseeing vehicles, native apps carry a fundamental commercial problem: friction at the moment of boarding. A tourist arriving at a dock for a 60-minute cruise does not want to open an app store, search for the operator's app, download it, create an account, grant permissions, and figure out how to start the tour. Several of those steps will happen while the boat is already moving. Many passengers simply will not complete the process.
Adoption rates for mandatory app downloads on short tourist experiences are poor, and the passengers least likely to complete the process are often older international visitors, who are frequently the majority on European river cruises. QR-based browser systems sidestep this entirely. Passengers scan, select a language, and listen. No download, no account, no setup. The operational and commercial case is straightforward.
The Real Problem with Browser-Based GPS Triggering
This is where the conversation gets more technically interesting, and where most providers either go quiet or offer explanations that do not fully hold up in practice.
Browser-based audio guides can request GPS access through the standard Geolocation API. In principle, this allows automatic triggering: the passenger's phone tracks its own position, and when it enters a defined zone near a point of interest, the relevant audio plays automatically. In practice, this approach has several serious failure modes on real vehicles with real passengers.
iPhone permission layers. On iOS, location permissions can fail at several different layers: the system settings, the browser-level settings, or the website-level permissions. A passenger who tapped "Allow" once may still have GPS silently blocked at another level they never saw. From the passenger's perspective, these failures are indistinguishable from a working system, which makes them very difficult to diagnose or resolve on a moving boat.
Background tab suspension. When a passenger switches from the browser to their camera app to photograph a landmark, the browser tab is suspended and geolocation updates stop. Audio triggering stops. The passenger takes their photo, returns to the browser, and has missed the commentary for the exact landmark they just photographed.
Device variation. A group of 40 passengers boards with 40 different smartphones. Some have recent flagship devices with excellent chipsets. Others have budget phones that are three or four years old. Also, the accuracy of geolocation varies dramatically between browsers and there is no way to control it.
Battery anxiety. Tourists are acutely aware of their phone battery during a full day of sightseeing. Many passengers proactively disable GPS, deny location permissions, close background tabs, or activate battery-saving mode before they even board. These are rational individual decisions that collectively make GPS-dependent triggering unreliable. A system that requires passenger cooperation to function is a system that will fail unpredictably.
These are not theoretical concerns. They are the operational reality of running GPS-triggered commentary at scale on vehicles where you have no control over passenger devices.
The same problems apply equally on land. A hop-on hop-off bus crossing a city centre faces urban canyon effects, where tall buildings block GPS signal for stretches of a route. A tourist train running through a mountain tunnel loses positioning entirely for minutes at a time. In all these cases, distributing the GPS problem across passenger devices multiplies the failure points rather than solving them.
What About an Onboard Wi-Fi Server?
A different category of providers takes a hardware-first approach: a dedicated box installed on the vessel creates a local Wi-Fi network, serves audio content from onboard storage, and uses its own GPS receiver to trigger commentary. Passengers connect to the boat's Wi-Fi rather than using mobile data.
This approach does solve the GPS problem properly. The GPS runs on operator-controlled hardware, not on passenger phones, which means no permission issues and no dependence on the chipset quality of individual passenger devices. For routes with genuinely zero mobile coverage — a fjord tour, an underground river, an enclosed mountain pass — it is a legitimate solution.
But it carries a set of tradeoffs that matter significantly for most urban and harbour operators.
Every vessel needs its own hardware. A fleet of ten boats means ten boxes to purchase, install, and maintain. Beyond the box itself, GPS antenna cables, power lines, and any external cellular uplinks all have connectors that vibrate loose on diesel engines — and a dead GPS antenna means no triggering until someone physically traces the fault. Hardware costs in this category typically run in the range of several thousand euros per unit before installation, content setup, and annual support contracts. That is a capex commitment before a single tour runs, and it scales linearly with fleet size.
Passengers must leave mobile data behind. When a smartphone joins a Wi-Fi network, it drops its cellular connection. Unless the onboard box is bridged to an external internet uplink — which adds cost and complexity — passengers lose access to WhatsApp, Google Maps, Instagram, and everything else that requires the internet for the duration of the tour. iOS makes this worse: when a phone joins a local network with no internet access, it displays a warning asking whether to "Use Without Internet" or switch back. Many passengers tap the wrong option and never successfully connect. Others who do connect will drop off the Wi-Fi halfway through when they want to send a photo.
Joining the network is a manual step with real drop-off. Even when these systems avoid the most restrictive form of captive portal by using a simple password and a QR code that opens directly in the normal browser, passengers still have to manually switch Wi-Fi networks in their phone settings before anything else can happen. That step alone — find the network name, tap it, wait for the connection, dismiss the iOS internet warning — is where a meaningful share of passengers, particularly older visitors and those navigating an unfamiliar phone interface, give up.
Content updates require active management. Updating audio tracks or routes on a fleet of hardware boxes means either physical access to each unit or purpose-built remote management infrastructure. A route change that takes minutes to deploy on a server-based system can mean a visit to every vessel in the fleet.
Marine environments are hard on hardware. Humidity, salt air, vibration, and temperature variation degrade consumer-grade electronics in ways that are difficult to predict and expensive to fix mid-season. A box on a boat is not a box in a server room.
For the typical urban harbour tour, river cruise, or hop-on hop-off bus operating in areas with at least intermittent mobile coverage, the hardware approach introduces substantial upfront cost and ongoing complexity without delivering advantages that a properly architected software solution cannot also provide. The clearest way to frame the difference: hardware-based systems put the infrastructure on the operator's vessels. Software-based systems put it on the provider's servers. When something breaks or needs updating in a software system, the operator never needs to know.
Moving the GPS Off Passenger Devices Entirely
The architectural insight that resolves most of these problems is surprisingly simple: stop asking passenger smartphones to handle GPS positioning individually.
Instead, positioning can be centralised on the operator side and synchronised across all connected passenger devices. This removes the need for passengers to grant location permissions, manage GPS settings, or keep browser tabs active in the foreground. The technical complexity stays where it belongs: on the operator's side, where it can be controlled and monitored.
Passengers receive no GPS prompts, grant no permissions, and need no particular device or browser. They scan a QR code, choose their language, and the audio plays at the right moment.
One passenger who experienced this system on a harbour tour in Bilbao described it in five words that are probably the best product review we have ever received: "I don't know how it works. But it really does."
That invisibility is the point. The complexity is entirely on the operator's side, where it can be controlled. The passenger experience is effortless.
There is also a social dimension worth noting. Because triggering is centralised, all passengers hear the commentary about the old cathedral at exactly the same moment. Everyone looks left together. That small synchronisation creates a shared experience that a PA system achieves through force and that passenger-GPS systems, where each phone triggers independently at a slightly different time, cannot reliably achieve at all.
Content delivery is handled separately from triggering. Audio preloads onto passenger devices when they first scan the QR code, so playback continues smoothly even if the vessel passes under a bridge, enters a tunnel, or crosses a stretch of river with no mobile coverage. By the time connectivity drops, the content is already there. Nubart's approach to offline mode is designed precisely for environments like these, where connectivity is intermittent rather than absent.
How Triggering Zones Work: Lines, Not Just Circles
Most GPS-triggered systems define trigger zones as radius circles around a point of interest. When the vehicle enters the circle, the audio plays. This approach works for walking tours, where the direction of approach is unpredictable. For vehicles following a fixed route, it is a blunt instrument.
A more precise alternative is the directional trigger line: a virtual line drawn across the waterway or road at a specific point. When the vessel crosses the line, the commentary triggers. Because the line has a defined direction, the system knows which way the vessel is crossing it.
This matters in practice for boats that follow a return route. A trigger line can be configured to fire only when crossed in the outbound direction, preventing the same commentary from playing again on the way back. Or, if the operator wants passengers on the return journey to hear a different track when passing a landmark from the other side, the line can be set to trigger in both directions independently, with different audio assigned to each crossing. Radius circles cannot do this.
When GPS Is Not Enough: Time-Triggered Fallback
Even with a well-positioned dedicated device, some routes pass through areas where GPS signal is genuinely unreliable. Urban canyons, bridges, tunnels, and certain enclosed harbour areas can interrupt positioning for long enough to cause missed triggers.
The practical solution is hybrid triggering: GPS-based firing for the majority of the route, with time-triggered sequences as a fallback for known dead zones. The operator defines which segments of the route are problematic, and the system advances through those stops on a timed schedule rather than waiting for a GPS event that may not arrive. Combined with preloaded offline content, this gives operators confidence that commentary will play correctly regardless of local signal conditions, without requiring manual intervention from the captain or crew.
What to Ask Any Provider Before Signing
The market for vehicle-based audio commentary systems is growing, and the marketing language used by most providers does not make it easy to distinguish between approaches that work reliably and those that depend on things outside the operator's control. Before committing to a system, ask these specific questions:
Where does the GPS run? If the answer is "on each passenger's smartphone," ask what happens when a passenger's iPhone has location permissions only partially enabled, or when they switch to their camera. The answers will tell you a great deal about how seriously the provider has thought about real operational conditions.
How are trigger zones defined? Radius circles are simpler to implement. Directional lines are more precise. For fixed routes on boats and buses, lines with direction logic are the better choice.
What is the fallback for low-connectivity areas? Any provider who says GPS works everywhere on water has not operated on many rivers.
Does the passenger need to do anything for triggering to work? The right answer is no. If the passenger needs to keep a tab open, grant location permissions, avoid switching apps, or keep their screen awake, those are not features. They are operational risks that will produce inconsistent results across 40 different devices.
Has any operator been running this in production for more than two years? Demonstrations are easy. Long-term operation on real routes with real passengers is the only meaningful test.
Nubart MOTION uses the approach described in this article: a dedicated operator-controlled device handles all GPS positioning, directional trigger lines replace imprecise radius circles, and hybrid GPS with time-based fallback covers areas with poor connectivity. The passenger experience requires no app download, no location permissions, and no active involvement. Several operators across Europe have been running it in live commercial operation for multiple seasons.
If you are evaluating options for your vessel or vehicle fleet, we are happy to configure a custom demo on your actual route before you make any commitment. Get in touch here.