Passenger counting in public transport: how a count reaches the report

In public transport a passenger count is rarely the goal. It is an intermediate step - towards a report to the authority, a settlement within a fare network, an investment case for new vehicles.

So the value of a count in public transport is decided by two questions hardly anyone asks in other sectors: how long does it take for the number to reach the report? And can the recipient check that it arrived unchanged?

This article follows a count from the vehicle door into the export file. It builds on Measuring occupancy, which covers the difference between a count and a balance, on What a counter can tell apart, which covered objects such as bicycles and prams, and on The half outage, which explains why a day starts in local time - and so also why the export does not.

The sample from two years ago

Manual passenger counts are expensive, infrequent and already old by the time they are analysed. Decisions on frequency, vehicle size and routing therefore often rest on a counting week two years back, extrapolated to a year that went differently.

Automatic passenger counting - APC in the trade - replaces the sample with a full count. The change is bigger than it sounds: one value per year becomes one value per vehicle and hour, every day. A line whose demand shifts in spring gets noticed in spring, not at the next counting campaign.

From the door to the line

Counting happens at every door, with a sensor above the opening. The count on its own, however, says nothing about a line yet. For that it needs an assignment, and that depends on a register.

The vehicle register holds what an analysis needs to know about each vehicle: capacity, class, registration, status, and which sensor sits in which vehicle. The line register holds which line a vehicle runs on. Count plus register gives boardings per vehicle, line and hour.

The register is the part that needs the most care in operation, and the part the quality of the analysis depends on. A vehicle that changes line without the register knowing counts for the wrong line - at full accuracy.

The expectation line

A boarding figure on its own says little. 1,400 boardings on line 12 on a Tuesday is a lot or a little, depending on what a Tuesday on line 12 usually brings.

So alongside the hourly and 7-day curves there is an expectation line from the same weekday in the preceding weeks. Same weekday is the point: a Tuesday in public transport has a different profile from a Saturday, and an average over all days would set every Tuesday against a profile that does not exist.

Deviations from that line show up at once, and where they arise - on a particular line, at a particular hour.

What the on-board hardware has to withstand

A sensor in a vehicle faces a different environment from one in a shop door. Vibration, temperature swings, voltage fluctuations from the on-board supply - and the fire-safety requirements for rail vehicles. There are standards for each, and a tender for on-board sensors should name them:

According to the manufacturer, the on-board sensors we use for rail vehicles meet the three rail standards and are designed for counting accuracy of up to 99 per cent, verifiable using the VDV 457 method.

That last point deserves one more sentence, because tenders often misread it. VDV 457 describes how the accuracy of a counting system is proven - in an acceptance test, on the real vehicle, with a defined sample. The figure on the datasheet is the claim; the acceptance is the evidence. Ask for both and you get both.

The report as a file, not a spreadsheet

Fare-network settlements and authority reports require count data in standardised formats. At many operators they are still assembled by hand in spreadsheets, weeks after the reporting period.

The standard formats have existed for a long time. ITxPT is the European initiative for an open, vendor-independent IT architecture in public transport, with its own data formats for exchange between systems. VDV 301 is the recommendation of the Association of German Transport Companies (VDV) for IP-based communication on board, known as IBIS-IP.

The export delivers count data as ITxPT S02P02 in JSON or XML, as VDV 301 XML or as CSV - in a single call, per vehicle, direction, counting class and timestamp. Bicycles, prams and wheelchairs appear as counting classes of their own. How to read those object figures - as sightings, not entries - is covered in What a counter can tell apart.

The difference from manual work is not just time. A file generated from the count data contains exactly that data. A spreadsheet someone put together contains what they put together.

The checksum: what the recipient can verify alone

A file sent to an authority or a network partner raises a question nobody likes to ask: is this the file the system produced? Or did somebody add, remove or correct a row along the way?

So every export file carries a SHA-256 checksum. The recipient recomputes it over the records themselves. If it matches, the records are complete and unchanged. If it does not, they know something has changed - without asking and without having to take the sender's word for it.

One detail decides whether that works in practice: the checksum is formed over the sorted, canonicalised records. Canonicalised means brought into one unambiguous notation in which the same data always yields the same characters - the same field order, the same representation of numbers and timestamps. Without that step, the same counts in a different order would produce a different checksum, and every recomputation would fail although nothing had changed. A checksum that raises the alarm on correct data is one nobody checks for long.

Why the export works in UTC

Anyone who has read The half outage knows how much effort goes into making every day start in the site's local time. The ITxPT export does exactly the opposite - it forms its time windows in UTC.

That is not a contradiction but a requirement of the target format. A file exchanged between operators, networks and countries needs a time reference that is the same everywhere. Local time belongs in the analysis a person reads; UTC belongs in the file another system reads.

You only need to know it. Compare a daily total from the dashboard with one from the export file and, in Switzerland, you are comparing two days offset by one or two hours - depending on the season.

What the time to report changes

Where a monthly report is assembled by hand in spreadsheets, every submission costs staff time, and every day spent preparing it is a day the number grows older. So the lever is not in the number, but in the time until it can be used. A passenger count that lands in the report three weeks after month-end steers nothing. One that is available as a verifiable file on the first day of the following month can.

A station is a site too

Vehicles are one half of public transport. The other is stations, stops and interchanges - and there everything applies that applies to any other site, with a few particulars.

• Thresholds in both directions. An overcrowded platform is a safety risk. An empty waiting area at night is one for the person working there alone. An occupancy threshold can therefore alert on crossing upwards and downwards, each in the station's local time and per time window.
• Cleaning by use rather than by calendar. Escalators, lifts, toilets and waiting rooms are mostly serviced on schedule - the heavily used ones too rarely, the lightly used ones too often. A cumulative counter per installation triggers the job after a freely chosen number of passages and then starts again.
• Retail space in the station. Each retail unit becomes a zone, with capture rate, dwell time and engagement. That makes it measurable which space benefits from the passenger flow. How those metrics are calculated and read is covered in Measuring dwell time and The visitors who don't buy.
• The security checkpoint at the airport. Per lane, people queuing and people being served, plus a public board without login that lets passengers spread themselves out with a pointer to the best lane. The metrics behind it are covered in Measuring queues and wait times.

Vehicle boardings and station counts sit in the same database, by the minute, for 730 days. An investment case for a platform extension can therefore rest on two years of measurements instead of one counting week.

What belongs in the tender

1. Which rail standards does the on-board sensor meet, and how is accuracy accepted - by which method, with which sample?
2. How are counts assigned to vehicles and lines, and who maintains the register?
3. Which formats are exported, and is the export a call or a project?
4. Can the recipient verify the completeness and integrity of a file on their own?
5. Which time base does the file use, and which does the dashboard?
6. Do vehicle and station counts sit in the same database, and for how long?

How we do it

The ANALYSIT Counting System assigns boardings to vehicle and line through a vehicle and line register - with capacity, class, registration, status and sensor assignment - and shows hourly and 7-day curves with an expectation line from the same weekday in previous weeks. Counts are kept by the minute for 730 days.

The export delivers ITxPT S02P02 as JSON or XML, VDV 301 XML and CSV in one API call, with objects as counting classes of their own and a SHA-256 checksum over the sorted, canonicalised records.

At stations and stops the same tools apply as at any site: occupancy thresholds in both directions in local time, a cumulative usage counter per installation for cleaning and maintenance, capture rate and dwell time per retail unit, and queue status per checkpoint lane with a public board.

If you have a passenger-counting tender coming up, or the next report is about to become manual work again, talk to us. The question of the export format is worth asking before the choice of hardware.