Blijft een wegenwerk staan zoals aangekondigd?

The Antwerp Disruption Reliability Report

What we measured: whether a roadwork, once published on Flanders' official GIPOD register, stays as published.

Window: 2026-04-11 to 2026-08-24. 136 calendar days. Every figure in this document is a count of rows in our own daily archive of the public feed.

Headline finding

Half of the roadworks published around Antwerp do not stay as published. 45 of 93 changed their announced start or end date, or vanished from the public register and came back with new ones, inside four and a half months.

Two honest qualifications belong next to that number, not in a footnote:

1. The 93 works cover a 15km ring around Antwerp centre, which includes Lier, Kontich, Brasschaat, Schoten, Ranst and Boechout. Restricted to the ten Antwerp city districts the figure is 29.5% (13 of 44). The confidence intervals overlap (38-58% against 18-44%), so we cannot claim the city is genuinely better. We can only say the headline number is a regional one.
2. Four and a half months is the entire archive. There is no year of history behind this, and section "What we cannot answer" explains why there never can be one retroactively.

An alternative headline, smaller sample but a cleaner mechanism:

Nine roadworks disappeared from Antwerp's public register for a median of 30 days. All nine came back with a different end date.

Method

Where the data comes from

A cron job has fetched the GIPOD INNAME collection (occupations of the public domain) within 15km of Antwerp centre once a day since 2026-04-11, and written one row per work per day into disruption_snapshots. GIPOD itself publishes only current state. It offers no history and no point-in-time query. The archive is the history.

Three captures we threw away, and why

An archive built by a pipeline that keeps changing will record the pipeline's changes as if they were the street's. Each of these was found by looking for days where too many works changed at once, and each is excluded rather than averaged over.

2026-04-12: the Schelde filter. Commit 0548d15 added a river-barrier filter to the fetch. From 2026-04-13, 24 works on the far bank stopped being returned. Their end dates run to 2027, 2040 and 2046. They did not finish, we stopped looking. Every longitudinal measurement here therefore starts 2026-04-13, and works last seen on or before 2026-04-12 are dropped.

2026-04-18: the backfill. A one-off run at 20km against a daily 15km ring. The 21 works it added beyond 15km were seen once and never again. Dropped by distance.

2026-08-22: a corrupted capture. Every one of that day's 91 works came back with a recurrence count of 20 or more, against 1 on both neighbouring days. That is the day commit cebf773 removed GIPOD paging after finding the offset parameter was being ignored. Until then the loop re-read page one, and our deduplication folded each work into itself around 20 times. Folding also rewrites the stored dates, so the rows are wrong about the works, not only about the counts. Left in, this single day would misclassify 63 ordinary one-off roadworks as recurring occupations. The whole day is dropped.

Two further days (2026-05-20 with 46 works, 2026-06-08 with 49, against a median of 93) are treated as non-observations rather than as evidence that works disappeared.

Dates are compared as Brussels calendar dates

On 2026-04-30 GIPOD re-serialised a batch of timestamps. 2026-04-23T05:00Z became 2026-04-22T22:00Z: the same local day, rendered from a different offset. Comparing raw strings counts 21 date "changes" that day that no reader would call changes. Truncating every timestamp to its Europe/Brussels calendar date removes the artefact and keeps every real move, so that is the unit throughout.

Recurring occupations are analysed separately

GIPOD's INNAME collection is every occupation of public space, not only digging. A weekly market carries the window of its next occurrence, so its dates roll forward seven days every week by design. 463 of the end-date shifts in the archive are exactly +7 days. Folding those into a "works change their dates" rate would turn the headline into a statement about market day.

We separate them using recurrenceCount > 1. Be aware this is our own field, not GIPOD's: it counts source records our deduplication folded together on matching description and location. Treating it as the recurrence flag is conservative, because a folded group's stored dates are the min-start and max-end of a set that can change between reads. Excluding those works removes the records whose dates we cannot attribute cleanly to a single source record.

The panel

93 is the denominator for every percentage in the next section. Median observation length in that panel is 96 capture days.

Findings

1. Announced dates move. Denominator 93.

Net drift from the first observation to the last:

The slip is not small. Among the 31 works that pushed their end date out, the median cumulative move is close to four months, and the largest is a full year (work 12842001 in Ranst, 2026-07-08 to 2027-07-08, announced in a single step on 2026-04-17).

Exposure-normalised, which is less sensitive to the sample size: 287 date-change events across 8,122 observation-days, or 3.53 changes per 100 observation-days.

Robustness. The same measure on narrower cuts:

The result does not depend on short-lived records. It does look different inside the city, on a sample of 44, with overlapping intervals. Report it as a regional figure.

2. When the end date slips, the notice is uneven. Denominator 33.

33 one-off works pushed their end date later at least once, across 210 events.

Measured per work, on that work's first extension, against the end date it was replacing:

So two thirds of works give real warning, and roughly one in five say nothing until the deadline they are missing has already gone.

The per-event view is dominated by one record and should not be quoted on its own: 130 of the 210 events belong to a single work (see below).

3. Works go dark. Denominator 94.

GIPOD's public endpoint only carries works whose end date is today or later. A work that runs past its published end therefore does not appear as delayed. It stops being published at all, and returns if and when somebody edits the end date forward. Anyone reading the live feed sees "no work here" for the whole gap.

Nine is a small number and the interval is wide. What makes it worth publishing is that the pattern is unanimous and the mechanism is documented rather than inferred: nothing in the live feed distinguishes "this work finished" from "this work is overdue and the register has stopped mentioning it".

4. One work's end date was permanently four weeks away

Work 12834344, Zwaantjeslei in Brasschaat, 360m of works. On 130 of its 131 observations its published end date moved one day later.

• First seen 2026-04-11, end date 2026-05-10. Twenty-nine days out.
• Last seen 2026-08-24, end date 2026-09-22. Twenty-nine days out.
• Net movement over four and a half months: +135 days.

At no point did the register publish a false date. On any given day it was accurate. It was also, for 131 consecutive days, exactly four weeks from finishing. A daily archive is the only thing that can see that; a live feed cannot, and neither can anyone who checked twice.

5. Lead time before works start is mostly fine. Denominator 26.

Only works that first appear after the panel starts have an observable lead time. Anything already present on 2026-04-13 was published before we started looking, so its lead time is censored, not zero. That leaves 26 of 94.

This is the one metric where the register comes out well, and it is reported here for that reason. The longest lead in the sample is 182 days. Six works appeared more than 100 days after their own start date, including two R1 Ringpark Zuid records first seen on 2026-08-23 with a start date of 2025-01-01.

6. A third of works have another work within 250m

As of 2026-08-24, of 91 panel works with coordinates:

• 20 pairs fall within 250m of each other.
• 35.2% (32/91) have at least one other work within 250m.
• The most crowded has two others within 250m.
• Across all 130 usable capture days: median 33.7%, range 27.3% to 39.1%.

Stable, not dramatic, and useful mainly as a floor: a business checking one work near its door has a one-in-three chance that it is not the only one.

7. Districts by observed disruption-days

One work observed on one capture day is one disruption-day. This is a count of rows, not an estimate of how long anything was actually dug up, and it is therefore biased toward works that are simply long.

53 of the 126 panel works fall outside the ten districts entirely, because the 15km ring reaches Lier, Ranst, Boechout and Schoten.

Ekeren is second on disruption-days with ten one-off works and almost no recurring occupations, which is the opposite composition to Antwerpen's. Berendrecht-Zandvliet-Lillo has no archived works at all.

What we cannot answer, and did not try to

There is no history before 2026-04-11, and there never will be. GIPOD's public INNAME endpoint only exposes works whose end date is today or later. A work that finished before the archive started was never fetchable and cannot be recovered. The backfill run on 2026-04-18 did not fix this: it wrote 120 rows, of which only 21 were works not already in the archive, and it re-read the same live collection at a wider radius. What it added is currently-active works carrying old start dates, not a historical record. Anything computed across the pre-archive period would be survivorship bias presented as history. Nothing in this report uses it. Any future chart that appears to show 2023, 2024 or 2025 must carry this warning or be deleted.

True duration overrun against the announced end date: dropped. It would need works observed running past their published end. GIPOD hides those. The only observable overrun is an extension, which is what finding 2 measures. Only 7 of 126 panel works were last seen with a finished status, which is not a sample.

Roadwork against transit-disruption overlap: dropped. Of 1,377 archived De Lijn rows, 36 carry coordinates (2.6%). Worse, before 2026-08-19 the disruption id came from Math.random(), so those rows cannot be matched to a disruption or to each other, and there is no time series. Since the fix there are 18 stable ids over 6 days. There is no overlap rate to compute, and inventing one from same-day co-occurrence without coordinates would be meaningless.

Anything using GIPOD's own kind, occupancyTypes or timeSchedule: avoided. Those fields have only been stored since 2026-08-20 and are absent from about 97% of the archive.

Limitations, stated plainly

• Small n. 93 works, one region, 136 days. Every share here carries a Wilson interval of 10 to 20 points. Treat these as first readings, not as settled rates.
• Region, not city. The panel is a 15km ring around Antwerp centre. 53 of 126 works are outside the ten districts. The headline rate is roughly 19 points lower inside the city, on 44 works, with overlapping intervals.
• Our own pipeline is part of the measurement. Three of the artefacts in this window were ours, not GIPOD's. We found them by looking for days where too many works changed at once, and excluded them. It would be dishonest to claim no fourth one is hiding.
• recurrenceCount is ours, not GIPOD's. It is a deduplication counter, and it decides which 94 works are in the panel.
• Missing captures are recorded, not interpolated. Three days have no GIPOD capture and two are half-sized. They are treated as non-observations.
• De Lijn contributes nothing to any finding here.