Fleet Map and Journey Presets

• Fleet map
• Journey presets
• Installer checklist

This is the full reference for this part of the dashboard. For everything else, see the main documentation.

A live map of where your routers actually are, colored by whether each one is online right now, under Network → Fleet map. Built for an operator running many locations at once rather than one fixed site — particularly a vehicle fleet (buses, taxis), where the routers themselves move. Has its own search box (same smart search as Journey presets) to jump straight to a place instead of panning/zooming by hand.

How the location is worked out. Every router already reports its own public IP address on its normal check-in (the same mechanism the Abuse & IP complaints tool relies on). That IP is run through a free, offline IP-geolocation lookup — genuinely accurate to city/area level for a router sitting at a fixed location, shown as a plain dark dot. For a router on a mobile/cellular connection, such as an LTE dongle on a bus, this coarser IP-based method only resolves to wherever that connection is registered on the mobile network — not the vehicle's exact position, and it will not move in real time from IP alone. Where a router's agent actually supports GPS and is reporting a fresh fix (within the last 10 minutes), its real live position is shown instead, marked with a distinct blue ring so it visually reads as "genuinely live," and moves as the vehicle travels. Whether a given router supports GPS at all is auto-detected and shown in that router's Manage panel.

A router that hasn't reported a public IP yet (brand new, or not yet connected) has nothing to plot and is listed below the map instead of silently missing — it appears on the map itself the first time it checks in.

Many routers close together group into a single number badge (standard map-clustering, the same idea ride-hailing apps use to avoid a wall of overlapping icons) — click it to zoom in and see the individual routers split apart. Marker size also scales with zoom, smaller zoomed out and bigger zoomed in, so a country-wide view of a large fleet doesn't feel cluttered.

Your own location, and directions to a router. Allow location access when your browser prompts you, and your own position shows as a distinct blue marker on the map. Click any router's marker and use "Get directions" for a real driving distance, duration, and route line to it — worked out with your own GraphHopper key, the same one Journey presets uses for trip estimates. Without a saved key (or if a real route can't be found), this falls back to a straight-line distance and compass direction instead, so it's never a dead end.

Satellite, live traffic and road incidents. The layers button at the top right of the map (also on the Journey presets route planner) switches between Street and Satellite. Satellite imagery comes from Esri with place names on top. The round target button at the bottom right jumps the map to your own location, like Google Maps. Live traffic (roads coloured green, orange and red by how slowly traffic moves) and Road incidents (accidents, road works, closed roads, jams, flooding, broken-down vehicles, each a coloured dot you can tap for the details, road names, expected delay and end time) need your own free TomTom key. Under the map, in Map settings, paste a key made at developer.tomtom.com. Every account uses its own key, so your usage and free allowance are yours alone; the key is checked with TomTom before it is saved, kept encrypted, and never shown again. Only the account owner can add or remove it. Incidents load for the part of the map you are looking at, so zoom in if you see a request to. The map refreshes traffic and incidents by itself every minute while a live layer is on and the page is open, and shows when it last updated. Each incident has its own badge (a no-entry bar for a closed road, a cone for road works, a car with sparks for an accident, a queue of cars for a jam, waves for flooding and so on), and bigger badges mean bigger delays. TomTom updates its traffic data about once a minute, so the colours change in steps rather than moving smoothly.

Timetable times on journey presets. In the route planner every stop has a Timetable time field. Type the time your timetable has the bus at that stop. A bus normally does not leave a stop before its timetable time, so the planner treats it as the earliest departure: the bus leaves at the later of the timetable time and (arrival plus waiting). Once stop 1 has a time and you press Get estimated duration, each stop shows when the bus is expected to arrive and leave and whether it is running behind the timetable, and the trip duration becomes first departure to last arrival. With a TomTom key saved, each leg is timed for the hour the bus will really be on that road, using live traffic for a trip starting now and typical traffic for later times. Without a key it falls back to the GraphHopper key if you have one. This is a prediction from timetable, traffic and your waiting times, not a live tracker.

Full guide: Fleet Map and Journey Presets.

Street name, journey status and trail in the popup. Click a bus on the Fleet map. The popup now says which road it is on (for example "N1 near Winburg"), using TomTom with GraphHopper as the back-up. For a bus that is on a tracked journey it also says which stop is next, in about how many minutes, and whether it is on time or running behind the timetable; a late bus shows an amber dot on the map. "Show trail" draws where the bus has been for the last 6 hours and, when Snap to Roads is ticked on your TomTom key, smooths it onto the roads it really drove. The trail is kept for 7 days.

Directions with live traffic. "Get directions" now gives the driving time with live traffic and says how many minutes of delays are in it. If TomTom has no answer for a place, GraphHopper is used instead, and the other way round, so either key alone works and both together are best. The same goes for place search: both are tried so a place one of them does not know can still be found by the other.

Which TomTom APIs to tick when you create your key. In your TomTom account, tick Traffic API (live traffic colours and road incidents) and Routing API (traffic-aware journey times and live arrival estimates). Those two are required. Tick Search API and Geocoding API as well if you want TomTom to help with place search and the road name in a bus popup, and Snap to Roads if you want a bus's trail smoothed onto the roads it drove. Anything not ticked simply stays off; nothing breaks. A GraphHopper key (Journey presets) is optional and works as a back-up for routing, place search and street names, so either key alone is enough and both together is best. Each tenant uses its own keys.

Bus stations on the map. A router you have marked as a bus station (Network, Routers, Manage, Bus station) is drawn with its own bus-stop icon, separate from your buses. Like places on Google Maps, nothing is drawn at country level: the icons appear once you zoom in close (about city level), the station name appears beside the icon when you zoom in a little more, and a "Bus station" line appears when you are very close. Zoom out and they disappear again; while they are hidden a small hint at the bottom left says how many stations you have, with a Show button that takes you to them. A station sits where you pinned it in its panel; if you never pinned it, the pin of a route stop with the same place name is used, and the popup says so. A station that matches nothing is listed under the map as having no position. Click a station to see its buses.

Only 3 buses at a time in a station popup. A station can list many buses, so its popup shows the 3 most relevant: buses that are on sale now come first, then the soonest expected departure. A bus that is running late is placed by when it will really leave (from its live GPS), not by its timetable time. Buses that left more than 10 minutes ago, or that are not on sale now, go to the back. When there are more than 3, the next 3 rotate in every 5 seconds (paused while your mouse is over the popup), with a line such as "Showing 1-3 of 7 buses, soonest first" and small dots showing which page you are on. The popup shows the same lateness and distance figures as the station's Manage panel.

Get directions works like Google Maps. "Get directions" on a bus or a station opens a panel under the map with a From list and a To list. The place you clicked is already the destination, and the start is My location when your browser allows it. Change either list to start from another bus, router or bus station, or use the round swap button to reverse the trip; the route is recalculated each time. The result shows the road distance, the driving time, whether there is live traffic or how many minutes of delay it adds (when your TomTom or GraphHopper key can provide it), and the compass direction in words, such as "NNE, north-north-east". The route is drawn along the real road, and an "Open in Google Maps" button opens the same trip there. If your location is blocked the panel tells you to choose a station or router as the start instead, so it is never a dead end. The lists show about 3 rows at a time and have a Search box, so a large fleet stays easy to use.

For an operator running fixed routes — buses, taxis, shuttles — rather than fixed sites: a preset that sizes how long access lasts to an actual trip, not a flat duration. Found under Vouchers → Journey presets. Works across every unlock type this platform has (ads, surveys, data plans, vouchers, and the API) — it's a shared duration override, not a feature bolted onto just one of them.

Two numbers, kept deliberately separate. Trip duration is the real expected travel time. Grace period is extra time added on top, for a big terminal city where the vehicle is still navigating to the actual stop well after entering the city limits — a bus reaching Bloemfontein, for example, isn't at its terminal the moment it crosses into town. Access expires at trip duration + grace period, never before. Keeping these as two fields (rather than one inflated duration number) means the trip-duration figure stays honestly the real travel time, not a padded guess someone has to remember to keep re-padding.

Two ways a guest ends up on one. Without a booking-system integration, this is passenger self-select: your guest-facing portal offers a "which route are you on?" choice alongside the normal ad/survey/voucher/data-plan flow, and whichever preset they pick overrides that flow's usual duration. With the Voucher Presets API, it's fully automatic — your booking system already knows the exact trip at ticket-purchase time, so it passes the journey preset's ID along with the voucher-issue or WiFi-grant call, and the correct duration is baked in with zero passenger input at all.

Optionally restrict a preset to specific routers — useful when different buses run different fixed routes, so a passenger on the Cape Town coach never sees the Durban route as an option. Leave every router unticked for a preset any of your routers can offer. This also closes a real fare-evasion gap, but only when combined with per-stop pricing below: a preset that's BOTH router-restricted AND has per-leg prices keeps a passenger's access working only on that route's own router(s) — buying the cheap short leg then walking onto a pricier bus in the same fleet won't carry that access over. A router-restricted preset with no distance pricing, or a distance-priced preset left open to every router, is untouched by this — ordinary WiFi access (a shop, hotel, or office) always keeps following a guest across your whole fleet exactly as it always has; this narrowing only ever applies to the specific bus-fare case it exists for. Every "restrict to specific routers" checklist on this platform (here, Data plans, External voucher bundles, Generate vouchers, Voucher presets) has a search box and caps what's shown at once — built for a fleet large enough that a flat list of every router would otherwise be unusably long; type a name or router ID to find the one you want, and an already-ticked router stays selected even once it's scrolled out of view by a search.

"Pick the route on a map instead" replaces guessing the trip duration by hand: search for a place by name to jump the map there instead of panning/zooming by hand, then click each real stop along the route in order — first click is where the trip starts, last is where it ends, anything in between is a genuine pickup/drop-off stop (up to 12 total). Each stop also has an optional "wait here" minutes field for a real dwell — a water break, a rest stop, a scheduled layover — that adds to the total on top of driving time. Estimating returns the driving time leg by leg, summed with any wait minutes into a total, drawing the actual road-following direction line on the map so you can confirm it picked the right road, not just a straight line between points. All of this pre-fills the trip duration field above. This is admin-only, one-time setup — it never reads or tracks any guest's location, live or otherwise, and it's a genuinely different thing from Fleet map (which shows where your routers are, not where any person is). Treat the estimate as a starting suggestion, not a guarantee — it doesn't know about real traffic, scheduled stops, or a breakdown, which is exactly what the separate grace period field above is for. Both the search box and the duration estimate need your own free GraphHopper API key, entered once at the top of this page (Journey presets → "Your GraphHopper API key") — sign up at graphhopper.com. This is deliberately your own key rather than one shared across every ISN tenant, so usage and any cost stays yours as your fleet grows, the same way your payment gateway and router-controller keys already work. If no key is saved yet, both the search box and the map button tell you plainly and you can still pan/zoom and enter the duration by hand.

Delayed trips — automatic recovery, if your router reports GPS. A fixed trip duration + grace period can still run out while a bus is genuinely still on the road (traffic, a breakdown, roadworks). If a router is GPS-capable and reporting a live position, and you've saved your GraphHopper key, the platform checks every 5 minutes for a passenger whose access is about to expire on a route with a saved destination, recalculates the real remaining driving time from the router's current position, and extends just that passenger's access to cover it — never open-ended: a single grant can never be extended by more than its own preset's trip duration (so at most double the originally planned time). Whether a specific router supports GPS at all is auto-detected and shown in that router's Manage panel; a router with no GPS hardware simply can't use this, and grace period is still the fallback for it. GraphHopper is a driving-directions calculator, not a live-tracking service on its own — this recovery only works because the router itself reports where it currently is. For a passenger who bought a journey-derived bundle for a specific stop rather than the route's final destination, this recovery recalculates toward THAT stop, not always the last one on the route — so a passenger getting off partway along a delayed route isn't extended based on how long it'll take other passengers to reach the very end.

Per-stop pricing — the piece that actually charges by distance. Once you've clicked out a multi-stop route on the map, each leg between consecutive stops gets its own price field (real fares are rarely a clean per-km formula, so this is admin-typed per leg, not calculated). An optional "Full route discount price" overrides the summed-legs total specifically for a passenger riding all the way to the final stop — leave it blank to just add the legs up. Naming a stop (e.g. "Harrismith") is optional but makes the bundles this generates far more readable than "stop 3". None of this charges anyone by itself — it only becomes a real, buyable product once you generate bundles from it under Data plans' Journey-based pricing.

"Runs roughly from ... to" (departure window) — covers a passenger who arrives early. Set this to roughly when the bus actually departs, and a passenger who buys before that time gets their total access extended to cover the wait too (capped at 3 hours), rather than the clock starting at the moment of purchase and leaving them with nothing while they wait to board — a bored passenger waiting at the terminal can still call home or browse. Leave it blank if the departure time genuinely varies too much to be worth setting; grace period still covers ordinary lateness either way.

Editing a preset, and generating its return trip. "Edit" on any preset reopens everything — stops, per-leg prices, full-route discount, departure window, router restriction — for changes, without needing to delete and recreate it. "Generate return trip" clones an existing mapped route with its stops (and their prices) reversed in one click, since a two-way route is the same physical road run backwards, not a different one to map from scratch — you'll still want to set its own departure window afterward, since an outbound and return trip essentially never run at the same time of day, and it's deliberately left blank on the generated copy rather than guessed.

A relief bus after a breakdown — moving already-paid passengers onto a different vehicle without them losing access — is handled on the replacement router itself, not here: see Routers.

Full guide: Fleet Map and Journey Presets.

Fare suggestions. After "Get estimated duration" a Fare suggestions box appears. Enter a price per km, a minimum per leg and how to round, and every leg gets a suggested price from its distance. You can change any leg afterwards. It is only a suggestion; the company always sets the real fares.

Delay-aware access time. When a bus has live GPS, a guest whose journey access is about to run out is extended just enough to reach their stop. The remaining time now follows your timetable: the bus will not leave a stop before its timetable time, the next leg is timed from where the bus really is with live traffic, and later legs use the planned drive times. The extension is capped per guest at the preset's own trip duration, as before, and if there is no timetable data it falls back to the plain drive time from the bus's position.

Stops the bus has already passed are not sold. Once a bus has reached a stop, that stop's bundle (and every stop before it) disappears from the passenger's list, and the purchase itself is refused if someone tries it directly, so nobody can buy a cheap pass to a stop the bus has already left. With live GPS the bus's real position decides. Without GPS (or when the bus is not on that trip) your timetable decides: type the departure time on the first stop and the minutes between stops, and a stop stops being sold the moment its due time arrives, with no grace period. Without GPS the system cannot see that a bus is running late, so put realistic times on your stops, with the usual delay already included. Once the trip is over, nothing on it is sold. With GPS the route closes when the bus reaches its last stop, and opens again when the bus is back at the first stop (within about 1 km) or starts the trip again; a bus that is currently running a different route has this route closed too. Without GPS the timetable does the same: bundles go on sale 60 minutes before the first stop's departure time and close when the last stop's due time arrives, and passengers who try to buy while the route is closed are told the trip is not running. A bus with neither GPS nor timetable times cannot be known, so nothing is hidden for it: add the timetable times. If anything is uncertain, nothing is hidden. Pre-sold vouchers and bookings made through the partner API are not affected.

Passengers pay for what is left of the journey. A bundle's stored price and time are for the whole route from the first stop. Once the bus has left its first stop, a passenger who boards later is shown and charged only the legs from the last stop the bus reached to their stop: never more than the bundle's full price, and never less than your cheapest priced leg (a paid bundle never becomes free). They get the time left to their stop plus the preset's grace period, with a small cushion on top (15 minutes with GPS, 30 minutes without, because a late bus cannot be seen without GPS). With GPS the time is the bus's live arrival estimate. The page shows the live fare with the full route fare beside it, and refreshes itself every 30 seconds. If the bus moves on while a passenger is looking, a stop that has just closed fades out of their list when they tap it, and a price that changed is shown to them before anything is charged. The system works out the price and time when the passenger pays and stores them with the purchase, so what is charged and granted is exactly what was quoted. Before the bus leaves its first stop everyone pays the full fare.

Journey bundles are grouped by route. Under Voucher bundles and Data plans, the bundles made from one journey route are listed together under a header with the route's name, how many bundles it has, the price range, how many are active and which routers they are on. The header has Edit route (opens that route under Journey presets), Rebuild from route, Activate all or Deactivate all, Routers (set the routers for every bundle of the route at once) and Delete all. Press the arrow to fold a route away; the page remembers which are folded. Every bundle underneath keeps its own Activate/Deactivate, Routers and Delete buttons. Bundles tied to specific routers are grouped under a header for each router (or each set of routers), so you see at a glance what each bus or venue router sells; bundles with no routers ticked are listed normally above them, under "On every router". When you choose a journey route in Data plans, Voucher bundles, Voucher presets or Generate vouchers, that route's routers are ticked automatically for you. You can tick or untick others before you generate, and if the route has no routers the bundles are offered on every router. The same grouping is used in Voucher presets (with Edit route, Rebuild from route, Activate all, Deactivate all and Routers on each route header; there is no Delete all, because a booking system may still use a preset, and a rebuild switches off the presets of stops that no longer exist instead of deleting them), in All vouchers (headers show unused, redeemed and void counts for the whole group, and only the first 150 rows are drawn), and in the Journey presets list (one header per router, and routes with no routers listed normally). After you change a route's stops, times or leg prices, press Rebuild from route: prices, durations and names are updated from the route as it is now, new stops get a bundle, stops that no longer exist lose theirs, and each bundle keeps its own on/off state and settings. If a route was removed under Journey presets, its bundles are still listed with a "route removed" label, and can be deleted.

Punctuality report. Under the presets list, the Punctuality report shows, for each preset, how many trips were recorded, the share of arrivals within 5 minutes of the timetable per stop and per weekday, and which legs usually run slower or faster than planned at which hour (for example "Winburg to Kroonstad is usually 22 min slower than planned when leaving around 07:00"). It can be exported to Excel. A bus is recorded at a stop when its GPS comes within about 250 m of the pin, and only presets that list their routers explicitly are tracked, so a taxi that merely drives past a stop is never counted.

Live next stop for guests, and how it is protected. A guest on a tracked journey sees a small note on the WiFi page: "Next stop: Kroonstad in about 18 min" and "Your stop: Pretoria in about 2 h 10 min", plus a line if the bus is behind its timetable. Guests never see a map, a position or a bus id, and only for the bus their journey access was bought on. The server quietly checks that the guest is really on that bus right now (their device is connected to that router), and, only if their browser has already been given location permission (it is never asked), that they are near the bus. If any check fails, for example someone who bought on the bus and got off, or who never boarded, they get exactly the same "nothing to show" answer as when no data exists, and the attempt is recorded. The Fleet map shows a warning box with the number of blocked attempts in the last 24 hours, masked guest hints and which bus. This estimate is a prediction from live position, traffic and your timetable, not a guarantee.

Bundles generated from a journey. In Voucher bundles, choosing the journey pricing mode creates one bundle for every stop after the first. Each bundle's price is the running total of the legs up to that stop (the last stop uses your full-route price if you set one). Each bundle's access time is the time from departure to that stop, following your timetable when the first stop has a timetable time (the bus does not leave a stop before its timetable time), plus the waiting time at the first and last stop and any grace period. Guests see it in plain words, for example "5 h 40 min" and never "5.67 hours". The bundles only appear on the buses listed in the journey preset, unless you pick other routers on the form, so passengers on a different bus never see them.

Each stop is one card. Under Journey presets, every stop on the route is shown as its own card so everything about that stop sits together: a numbered badge and the title ("Stop 1 (departure)", "Stop 2", "Stop 3 (destination)", with green for the start and blue for the end), the stop's name, then labelled boxes for Wait here, Timetable time and Price for this leg, a strip saying when the bus is expected and when it leaves (green "on time" or amber "N min behind the timetable"), and at the bottom the driving time to the next stop. The last stop has no price or driving line because nothing follows it. Nothing about how the numbers work has changed; only the layout.

Our own clock for timetable times. The clock button beside Timetable time opens our own themed time picker (hour and minute lists with Now, Clear and Done) right under the box, instead of the browser's plain one. You can still type the time as four digits such as 0730.

A step-by-step record for whoever physically fits a router, on that router's own Manage view under Network ? Routers (scroll to "Installer checklist"). Open it on the phone you are installing with. It has four parts: eight steps to tick off (mounted and powered, uplink working, WiFi name and password set, login page opens on a test phone, test login gives internet, guests cannot reach the router admin page, router labelled, venue contact shown how to use it); a location recorded from your phone's GPS; up to six photos with a label each (photos are shrunk on your phone before upload); and a speed test.

The speed test runs from the device you are holding. It downloads and uploads test data between your phone and this platform, so it measures what a guest at that spot would really get: the venue WiFi plus the venue's internet line together, not the router in isolation. It also records ping. Run it standing where guests will sit.

Mark install complete only works once every step is ticked and a location, at least one photo and a speed test are saved. Changing anything afterwards (a step, a photo, the location) re-opens the checklist so the record always matches what was last saved. View Only accounts can read the checklist but not change it, and Financial accounts cannot open it. Your phone will ask permission to share its location, and the location is only as accurate as the phone's GPS fix, which the page shows next to the coordinates.