The crew goes out with a printed list. The readings come back in a spreadsheet three days later.
And when you finally check them, one meter shows less than last month, another was not read and someone copied a digit wrong. By then the reader is already in another area. With Maptainer the campaign goes into the field with the map built in, an impossible reading is rejected on the spot and the data reaches the system without anyone retyping it.
What stops happening to you in every campaign.
- You stop sending people back because of a bad reading. Each point carries its validity thresholds on the device itself. An impossible reading is flagged on the spot, without coverage, and the reader retakes it or confirms it there and then.
- You stop building campaigns by hand. Batches are scheduled automatically from each point's frequency and shared out across the team.
- You stop arguing about whether the reader was actually there. Where the asset type requires it, the reading cannot be saved without its geolocated photograph.
- You stop keying readings into the billing system by hand. Measuring points and their readings go out through the public API, with incremental sync.
Static routes and scheduled batches.
Reading routes are fixed rounds: the order in which an area has always been covered. Campaign batches are scheduled automatically from each point's frequency and shared out across the team.
No coverage, and the campaign carries on.
The reading batch travels in its own SQLite database, separate from the general working database. It carries its points, its thresholds and its recent history, so the reader can check in the field whether the reading just taken makes sense, without coverage.
Thresholds that learn from the history.
- Validity thresholds Maximum and minimum allowed per point, so an impossible reading is rejected on the spot.
- Frequency How often each point should be read, which is what then schedules the campaigns.
- Recalculation from history Thresholds can be recalculated from the real behaviour recorded, instead of staying at the value set on day one.
A stuck meter shows up before the next campaign.
The system compares each reading with the point's previous behaviour and flags those that fall outside the pattern. It picks up abnormal consumption, a stuck meter or a reading error.
This is statistical anomaly detection. The difference from what is usually sold is not a fine distinction: it does not predict a failure, it points out a value that falls outside what is expected.
Readings go out through the public API.
Measuring points and their readings are exposed in the public REST API, with incremental sync and scopes. There is also a write scope for readings, for when they come in from another system.
It is the usual way of exchanging data with the customer's billing system. Maptainer does not bill: it delivers the measured data.
Frequently asked questions
Does it integrate with remote reading or sensors?
What happens if a reading falls outside the threshold?
Last updated:
Do you operate a water or metering network?
That page is written in your vocabulary, not ours.