Why AI analysis of human flows fails on urban data
Automated flow counting breaks not on the model but on the input data. A device riding in a car cabin and a pedestrian’s phone end up in the same sample, so AI analysis of human flows mixes pedestrian traffic with vehicle traffic.
The output shows inflated density on main roads and underestimated density in crossings between blocks, even though physically the picture is the opposite.
The second source is gaps in geodata. An event does not arrive every minute, some devices do not get into the log at all, and at zone boundaries the record breaks off.
The model fills the gap linearly and gets a smooth but incorrect profile: a peak at one point and an apparent lull at a neighboring point where people simply had not arrived at the time of measurement.
On top of this, traffic anomalies are at work: a fair, road repairs, a station closure for the weekend. A one-off surge enters training as the norm and shifts the seasonal component.
Recognition errors accumulate quietly — flow counting accuracy drops by half, while on the summary chart it looks like steady growth.
It is on such data that decisions about a site are made: an attraction point is placed where the flow existed for one week, and sustained demand in two neighboring blocks is not seen.
We explain how this is closed — from sample cleaning to validating the model on an independent measurement.
Measurable effect: accuracy, speed, and system resilience
The result of an AI flow analysis system breaks down into values that the customer can verify independently rather than take on faith.
The share of correctly recognized objects, the amount of manual reconciliation, and report preparation time we fix before the start — on a labeled sample of locations and time windows, and these same values go into acceptance.
We calculate recognition accuracy separately by types of road users: pedestrian, passenger cars, transit flow. In mixed flow, errors are distributed unevenly, so an overall system figure proves nothing.
Classification is refined using the layer of zones and infrastructure objects, whose geometry is taken from OpenStreetMap and then verified against actual tracks.
Report preparation time stops depending on manual labor: grid aggregates are calculated on schedule, and the export is assembled from ready-made layers.
Manual reconciliation is reduced to a control sample — the operator checks not the entire array but those records where the model showed low confidence and flagged them for review.
We separately close the class of failures that previously broke calculations: track gaps where signal is lost, duplicates when switching between towers, double counting at zone boundaries.
Session matching and deduplication remove them before aggregation, so a repeat run on the same data gives the same result. Calculations are reproducible, and discrepancies between two reports are always explainable — down to a specific location and hour.
Data sources and processing modes: what fits the task
The choice of source is determined by the question: is coverage of the territory, accuracy at a specific point, or retrospect needed.
Anonymized geodata from telecom operators show flows between districts, commuting migration, and daily profiles, but smooth out details within a block.
Own sensors are accurate at entrances and in narrow passages, but depend on installation, power, and weather — that is the price of detail.
Processing mode is the second axis of choice: online counting provides current load, while archive analysis reconstructs history and serves as a reference for calibration.
| Option | When it fits | Limitations |
|---|---|---|
| Anonymized geodata from telecom operators | A citywide or regional picture is needed: flows between districts, seasonality | Aggregation by cells; accuracy drops where one cell covers several objects; export arrives with a delay |
| Own sensors at the site | Accuracy at entrances, crossings, and parking is important; unique visitor counting is needed | Installation, power, and maintenance; blind spots and occlusions; signal quality depends on lighting |
| Archive processing | Retrospect: assess the effect of changes, compare seasons, validate the model on past data | Time lag; storage of raw records and labeling are required; not suitable for operational decisions |
| Online counting mode | Current load is needed: flow regulation, congestion alerts | Sensitive to communication and power failures; requires compute resource headroom and in-flight data quality control |
| Hybrid data collection | The task changes: control now, analytics and forecasting later | More complex to set up — different aggregation grids must be reconciled and sources calibrated against each other |
In practice, the scheme is almost always hybrid: geodata set the coverage, sensors refine key points, and the archive checks that the calculation has not diverged from reality. For the task, we choose a combination from this table and fix which limitations are acceptable for you.
How we implement the system: stages of engineering work
A flow analysis system begins not with the model but with a data audit. We look at which sources are available — anonymized telecom operator exports, transport tracks, building and event layers — and whether their density is sufficient for the required locations. If this step is skipped, the model will confidently count noise.
- Source data audit. We check the completeness, frequency, and quality of slices, find gaps and duplicates, and mark poorly covered districts and hours. The output is a data suitability map.
- Source reconciliation. We bring exports to a unified schema, anonymize them, and link them to each other so that one flow is described consistently regardless of source.
- Model calibration. We tune parameters for a specific city: building density, transport operating mode, seasonality. The model learns on historical slices, not on averaged templates.
- Control sample. Part of the data does not participate in tuning — we use it to compare the calculation with fact. This shows where the model errs systematically and where it errs one-off.
- Site validation. We compare the calculation with a manual count at control locations — an intersection, a node, a stop. A discrepancy above the threshold returns us to calibration, not to the report.
- Handover to operation. We deploy the system on your side, set up data updates and alerts, train the team, and hand over documentation.
What remains after launch
A regulation: how often to review the model, which deviations are considered grounds for recalibration, and who is responsible for data updates.
Documentation, diagrams, and regulations: composition of the handover package
The documentation package is assembled in parallel with development, not before delivery: a system described after the fact diverges from the actual state, and a month later no one uses such documents.
Below is what physically remains with the customer and allows the analysis of human and transport flows to be developed by their own team.
- Data flow diagram — from the geodata source to analytics marts: which fields arrive, where they are enriched and aggregated, where the raw layer is stored, and how often each section is updated.
- Calculation logic description — how flow intensity and density are calculated, how anomalies and stable routes are determined, and which rules cut off outliers and gaps in data.
- Access policies — roles and a permission matrix by objects and territories, separation of sensitive slices, the procedure for granting and revoking access, and logging of data requests.
- Data update regulation — the recalculation window, system behavior when a source is delayed or interrupted, the procedure for publishing a new model version, and rollback to the previous one.
- Team instructions — starting and stopping loops, diagnosing typical failures, actions for source degradation, and the points where an engineer is needed versus where the system handles it itself.
- Metric dictionary — unified definitions of metrics so that “flow” in the report and in the model means the same thing, without discrepancies between departments.
- Decision log — what changes were made to the calculation logic and why: during incident review, the cause is visible, not just the consequence.
Each document lives in the customer’s repository and is updated together with the code — a discrepancy is visible at review, not discovered at the moment of an incident.
Handover is not “we sent an archive”: we walk through the diagrams with the team, answer questions, and fix who is responsible for which loop after launch.
Case study: how counting accuracy changed at a real site
The site is a transport-pedestrian node with four approaches: two cameras looked along the roadway, two at pedestrian crossings.
The customer came with manual measurements during peak hours, and these were taken as the reference sample: raw trajectories, geozones, and object labels were stored in PostGIS to compare automatic counting with manual counting minute by minute.
At the start, agreement with manual measurement held at three out of four cases during the day and two out of three at night.
A group of pedestrians was taken for one object, reflections on wet asphalt produced false detections, and the trajectory broke when the flow of vehicles occluded a person. A separate problem was time desynchronization between cameras: the same car appeared in the report twice.
What was calibrated
Detection confidence thresholds were separated by scenario — daylight, night, precipitation — instead of one common threshold.
The full frame was replaced with regions of interest that cut off storefronts and reflections, and track stitching through occlusions was configured by direction of movement and disappearance time, not by proximity of objects.
Camera time was tied to a common source so that flows at the intersection would add up rather than duplicate.
What was achieved
Counting accuracy rose from 74% to 94% in daylight and from 61% to 88% at night, and the share of track breaks fell from a third to 6%.
The discrepancy with manual measurement during peak hours stays within 3–4%, and reports by hour and direction are built automatically — separate exports for reconciliation are no longer needed.
How does counting people from geodata differ from video analytics?
A camera and geodata measure different physical quantities. Video analytics recognizes objects in the frame and counts crossings of a given line, while geodata are aggregated anonymized registrations of subscriber devices in a service area.
This is why coverage, detail, and the range of tasks that it makes sense to assign to each source diverge.
Geodata win in coverage: they cover a city or region without equipment installation, work around the clock, and do not depend on lighting, weather, or angle. The price for this is resolution.
Flow is visible at the zone level, not the individual person level, and at small numbers the anonymization threshold kicks in, so some values arrive smoothed.
Distinguishing a pedestrian, a car, and transit through a district in the total volume is difficult without additional features.
Video analytics is strong at a point: it distinguishes object class, direction, and passage time, and provides a metric for a specific entrance.
But its error grows precisely where flow is most interesting — in a dense crowd, during occlusions, at dusk and in precipitation, at the junction of viewing zones where the same person enters two counters.
Added to this is a linear increase in coverage costs: to cover a district, proportionally more cameras, installation, and maintenance are needed.
Therefore, the choice of data source is dictated by the task, not by the convenience of the tool. If accurate counting at an entrance and breakdown by type are needed, we use video.
If the structure of flows between districts, daily and weekly rhythms, and territory coverage without equipment are needed, we work with geodata.
A combined scheme gives the best of both: video counting at reference points serves as a calibration standard, while geodata scale the picture to the entire city and link points to each other. Below we explain how we choose a source for a specific task.
Technical concerns: privacy, accuracy, and integration
Raw device identifiers do not leave our perimeter: at input they are replaced with pseudonyms using a salt that rotates on schedule, and only aggregates by geo-cells enter analytics.
Cells where the number of devices is below a specified threshold are not published at all — they cannot be used to reconstruct a specific person’s route.
Such a perimeter meets personal data protection requirements while keeping the data suitable for the model: aggregates show both flow distribution and daily seasonality.
On small flows, numbers behave differently — individual devices produce spikes that are easy to mistake for a trend.
We calculate accuracy on small flows explicitly: we build confidence intervals, smooth over time, and do not show a conclusion where the sample is below the threshold. The report shows not a single point but a range, so decisions are not made on noise.
Integration with the customer’s accounting systems is carried out through scheduled exchange.
We match object and zone directories, bring aggregates to your format, and deliver them to an already operating storage or reporting system — the system stands alongside and fills what you use, without restructuring processes.
Does the method provide absolute people counts?
No, and this is a deliberate limitation of the method. Geodata show relative flows and structure: where traffic moves from and to, how the profile changes by hour and day of week.
Absolute counts are more reliably taken from your record systems, while geodata are used as an explanatory layer for them.
What if some points do not return data?
We maintain a coverage map by zone and check it regularly. If a zone drops out, the flow through it is marked as incomplete rather than imputed by the model — otherwise the report would contain numbers that are not in the data. The gap is closed by adding a source or adjusting the zone boundaries.
Let’s discuss the task: where to start and what is needed from your side
The start of a project rests not on the model but on data and access: without historical slices and an understanding of how the sources are structured, neither architecture nor timelines can be honestly assessed.
Below is the minimum list of input data from the customer, after which we return with a work plan and estimate, not with clarifying questions.
- Goals and boundaries: what decisions you make based on the result — route priority, stop load, peak interval forecasting.
- Anonymized historical geodata slices for several periods, including anomalous days: holidays, repairs, failures.
- Directories and layers: stops, routes, schedules, district boundaries, and attraction points.
- Access to systems: data warehouse, event queue, transport monitoring panel — with read-only role.
- A person responsible for data on your side and the procedure for approving changes in sources.
- Requirements for the result export: format, where we write, who views the summary and how often.
- Personal data restrictions and rules for storing anonymized datasets.
Once the list is closed, we describe the processing scheme, test it on your historical slice, and show at which locations the model errs. After that, we fix the stages, scope of work, and timelines. Describe the task — we will return with an estimate and plan.
