Road Obstructions
A municipality already knows where its roads are closed. It approved the works weeks ago, and the approved plan is sitting in a mailbox. What it cannot do is get that knowledge into the vehicles driving through those streets tomorrow morning.
So the postal van meets the barrier, backs out and goes round. Then the home care visit. Then the waste truck, the service car, the inspection round. A few minutes per vehicle, per round, every day the works last. Nobody logs it and it never appears as a line in a budget, but it is paid daily, by the same organisation that issued the permit.
The same closure costs far more when an ambulance meets it, or a fire truck that cannot turn around in a narrow street. There the minutes spent backing out are the minutes that mattered.
In every one of those cases the information existed. It simply never reached the vehicle.
Yggio closes that gap. It turns obstructions into roadblocks, and every route Yggio calculates is calculated with the active roadblocks already applied, so the route goes around the blockage instead of ending at it. The complete route is returned over the API, which is what lets a fleet system or a navigation service pick it up.
Routing happens in Yggio today. There is no integration yet that pushes roadblocks into a third-party navigation service, so a vehicle gets the detour by asking Yggio for the route rather than by its own navigation app knowing about the closure.
An obstruction is the thing in the road, planned or not. A roadblock is how Yggio represents it, as a device, which is what makes it usable by everything else.
Where roadblocks come from
Two sources, and they run together.
Planned works, announced by email
Road works are announced in advance, as an approved traffic arrangement plan sent by email. The decision has already been taken elsewhere; the email carries the result. It is written for a person: free text, an attachment, a street name, a date range.
The Road Maintenance connector polls that mailbox, accepts mail only from senders you have allowed, and hands each message to an LLM agent that reads it and returns the details as structured data. A roadblock is created from the result.
The value here is that nothing changes for the people doing the announcing. They keep sending the same email to the same address. The reading is what Yggio automates, and reading unstructured documents is exactly what a language model is good at.
Unplanned obstructions, detected by sensors
Not every blockage is announced. A vehicle blocks a lane, an accident closes a street, a delivery stands where it should not.
Traffic sensors on the road see this as an anomaly: counts collapse, or speeds drop to nothing. The
set-road-blocked-if-traffic-anomaly translator
turns that pattern into a roadblock candidate, with the road name, the location and a geofence, so
an obstruction nobody reported still reaches the routing engine.
What happens to a roadblock
A roadblock is a device in Yggio, of the Road block device type, so everything that works on a device works on it: it appears on the map, in views and in reports, it can be shared, and its lifetime can be managed like any other data.
The road-obstruction flow publishes roadblocks to the routing service. Routes calculated
after that avoid the blocked segment, which is how a delivery round or a fire truck is sent round a
closure rather than into it.
Because the roadblocks carry a time range, a closure applies while the works are live and stops applying afterwards, without anyone having to remember to remove it.
The columns are an ordinary device view, so they are yours to choose. The one worth noting is
whether emergency vehicles may pass: that is the canPass decision the parser made from the email,
carried through to something an operator can read at a glance.
Routing around it
Yggio's map includes Navigation. Set a start and a destination and it returns the fastest route, calculated with the roadblocks already applied, so the route goes around a closure rather than through it.
Two things can be varied:
- Vehicle profile, Car or Truck. A truck is routed on roads that can carry it, which matters most when a detour would otherwise send it down a street it cannot use.
- Ignore one-way streets, for vehicles entitled to disregard them. An emergency vehicle may take a one-way street the wrong way where a delivery van may not, and that often decides whether a detour is short or long.
The same route is available to any system that can call the API, so it does not have to be read off the map. The response holds the complete route: the full list of coordinates along it, and the turn instructions. A fleet system, a dispatch tool or a navigation service can request a route and use the result directly.
Setting it up
| Step | Where |
|---|---|
| Create an AI connector of type Agent, with a prompt describing what to extract | AI Connector |
| Create the Road Maintenance connector against the mailbox, with allowed senders and the agent | Road Maintenance Connector |
Add set-road-blocked-if-traffic-anomaly to traffic sensors, for unannounced obstructions | State and occupancy translators |
Assign the road-obstruction flow so roadblocks reach the routing service | Data Flows, Timers and Geofences |
A note on trust
Two safeguards are worth understanding, because this feature can close a road.
Only allowed senders are processed. The connector ignores mail from any address not on its list. That list is the access control for the entire feature, so it should hold the contractors and case handlers entitled to announce works, and nobody else.
The LLM reads, it does not decide. Its job is to extract details from a document that a human already wrote and a process already approved. It is not judging whether a road should close.
Background
The approach was developed with the emergency services on Gotland, where the distances are long, the road network is thin, and a detour discovered at the barrier is expensive in exactly the situations where time is scarce.