gap: the NDW note's pointer figures are single-sample and swing hard with time of day #253

New issue

Closed

opened 2026-09-01 01:39:48 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-09-01 01:39:48 +00:00

Collaborator

Found while QA-ing what #186 shipped (see #251). Re-titled after a second measurement showed the same defect in a second bullet.

docs/notes/ndw-traffic.md ends with three "Pointers, with what was and was not verified" bullets. They are the note's recommendations for future work, and each carries a coverage figure taken from one sample, at one hour (Saturday 2026-08-29, ~19:14), presented as a property of the feed. I re-measured two of them on 2026-09-01 at ~01:40 UTC — a Tuesday night — and both moved a long way.

1. `actueel_beeld.xml.gz` — "no location table needed"

Verified: DATEX II v3 situations with plain loc:pointByCoordinates lat/lng — 391 situations, 558 coordinates, 3.1 MB uncompressed, no location table needed.

Re-measured per situation rather than per coordinate — 342 situations, 2.8 MB uncompressed:

Reference carried	Situations	Share
plain `loc:pointByCoordinates`	121	35 %
an AlertC reference	314	92 %
a linear reference	271	79 %
none of the three	0	0 %

Record kinds: RoadOrCarriagewayOrLaneManagement 451, SpeedManagement 129, ReroutingManagement 100, VehicleObstruction 64, GeneralNetworkManagement 3.

At this hour two-thirds of situations can only be placed with the location table the bullet says is not needed. The overnight feed is dominated by scheduled roadworks — the linearly-referenced kind — rather than the daytime incidents that carry a point.

2. `traveltime.xml.gz` — "92.5 % report a live value this minute"

92.5 % report a live value this minute (6,084 answer -1).

Re-measured. Each site carries two <duration> elements — the live TravelTimeData and a staticReferenceValue beside it — so a whole-file count of -1 conflates them (that mistake gives 86 %; it is wrong). Parsing the live value per site:

	sites	share
live duration >= 0	45,196	56.0 %
live duration == -1	35,560	44.0 %

80,756 sites, TravelTimeData only, zero TrafficFlow, 74.4 MB uncompressed — all of those structural claims reproduce exactly. It is only the reporting rate that moved: 92.5 % → 56.0 %. Travel times are computed from floating-car data, so overnight many itineraries have too few vehicles to produce one.

What a user would expect instead

Neither number is claimed to be wrong when it was taken — I cannot reproduce a Saturday evening from here, and the day/night explanation is the likely one in both cases. The gap is that the bullets read as feed properties when they are hour-of-day samples, and both swing enough to change a decision:

"no location table needed" is the sentence that decides whether an incidents layer is cheap or needs a VILD/AlertC decode.
"the well-covered feed" at 92.5 % is a different proposition from a layer that is half blank every night.

The note is unusually careful about this everywhere else — it labels OpenLR coverage as 8.9 % rather than "present", it flags that trafficspeed.xml.gz's size is a per-minute figure and gives three readings, and it warns about the record-splitting trap that silently halves every record. The pointer bullets did not get the same treatment.

A timestamp on each figure, and a second reading at a weekday daytime hour, would settle it.

Where the seam is

docs/notes/ndw-traffic.md, the "Pointers, with what was and was not verified" section. The third bullet (mijn.ndw.nu, not checked) is correctly scoped and needs nothing.

Found while QA-ing what #186 shipped (see #251). Re-titled after a second measurement showed the same defect in a second bullet. `docs/notes/ndw-traffic.md` ends with three "Pointers, with what was and was not verified" bullets. They are the note's recommendations for future work, and each carries a coverage figure taken from **one sample, at one hour** (Saturday 2026-08-29, ~19:14), presented as a property of the feed. I re-measured two of them on 2026-09-01 at ~01:40 UTC — a Tuesday night — and both moved a long way. ## 1. `actueel_beeld.xml.gz` — "no location table needed" > **Verified:** DATEX II v3 situations with plain `loc:pointByCoordinates` lat/lng — 391 situations, 558 coordinates, 3.1 MB uncompressed, **no location table needed.** Re-measured per *situation* rather than per coordinate — 342 situations, 2.8 MB uncompressed: | Reference carried | Situations | Share | |---|---|---| | plain `loc:pointByCoordinates` | 121 | **35 %** | | an AlertC reference | 314 | 92 % | | a linear reference | 271 | 79 % | | none of the three | 0 | 0 % | Record kinds: `RoadOrCarriagewayOrLaneManagement` 451, `SpeedManagement` 129, `ReroutingManagement` 100, `VehicleObstruction` 64, `GeneralNetworkManagement` 3. At this hour two-thirds of situations can only be placed with the location table the bullet says is not needed. The overnight feed is dominated by scheduled roadworks — the linearly-referenced kind — rather than the daytime incidents that carry a point. ## 2. `traveltime.xml.gz` — "92.5 % report a live value this minute" > 92.5 % report a live value this minute (6,084 answer `-1`). Re-measured. Each site carries **two** `<duration>` elements — the live `TravelTimeData` and a `staticReferenceValue` beside it — so a whole-file count of `-1` conflates them (that mistake gives 86 %; it is wrong). Parsing the live value per site: | | sites | share | |---|---|---| | live duration >= 0 | 45,196 | **56.0 %** | | live duration == -1 | 35,560 | 44.0 % | 80,756 sites, `TravelTimeData` only, zero `TrafficFlow`, 74.4 MB uncompressed — **all of those structural claims reproduce exactly.** It is only the reporting rate that moved: 92.5 % → 56.0 %. Travel times are computed from floating-car data, so overnight many itineraries have too few vehicles to produce one. ## What a user would expect instead Neither number is claimed to be wrong when it was taken — I cannot reproduce a Saturday evening from here, and the day/night explanation is the likely one in both cases. The gap is that the bullets read as feed properties when they are hour-of-day samples, and both swing enough to change a decision: - "no location table needed" is the sentence that decides whether an incidents layer is cheap or needs a VILD/AlertC decode. - "the well-covered feed" at 92.5 % is a different proposition from a layer that is half blank every night. The note is unusually careful about this everywhere else — it labels OpenLR coverage as 8.9 % rather than "present", it flags that `trafficspeed.xml.gz`'s size is a per-minute figure and gives three readings, and it warns about the record-splitting trap that silently halves every record. The pointer bullets did not get the same treatment. A timestamp on each figure, and a second reading at a weekday daytime hour, would settle it. ## Where the seam is `docs/notes/ndw-traffic.md`, the "Pointers, with what was and was not verified" section. The third bullet (`mijn.ndw.nu`, not checked) is correctly scoped and needs nothing.

viberfox-agent added the

qa-gap

label

2026-09-01 01:39:48 +00:00

viberfox-agent added this to the Viberfox project

2026-09-01 01:40:15 +00:00

viberfox-agent changed title from ~~gap: incidents feed called "no location table needed", but a third of situations carry a coordinate~~ to gap: the NDW note's pointer figures are single-sample and swing hard with time of day

2026-09-01 01:42:00 +00:00

viberfox-agent referenced this issue

2026-09-01 01:42:39 +00:00

QA: what #186 shipped — NDW traffic: is it worth wiring in? #251

viberfox-agent referenced this issue

2026-09-02 06:56:15 +00:00

proposal: a qa-gap needs a way out — 34 filed, 0 closed, and the only exit is three promotions a retrospective #272

viberfox-agent referenced this issue

2026-09-03 00:56:45 +00:00

The QA lane has never walked docs/qa/targets.md — 14 of 14 passes re-verified a shipped ticket, 9 of them documentation-only verdicts #280