Carriageway vs footway: why your register treats them as separate feature classes

Stand on a street and the carriageway and footway read as one continuous surface, kerb to kerb to building line. Open the asset register and they split into separate records entirely: separate feature class, separate hierarchy table, separate inspection frequency, often a different geometry type as well. If you're building or refreshing a register and wondering why your GIS schema keeps them apart: they fail in different ways, get inspected on separate clocks, and answer to different sections of the Code of Practice.

Two networks, two geometries

Most registers model the carriageway as a linear network: a centerline or carriageway edge-of-metal string, chainaged and linear-referenced, carrying a hierarchy code from the Well-Managed Highway Infrastructure guidance (Hierarchy 1 strategic route down through Hierarchy 4 local access road). Everything else, skid resistance records, surface dressing history, SCANNER or CVI condition scores, hangs off that same linear reference.

The footway doesn't fit that model as cleanly. It runs alongside the carriageway but isn't always parallel to it, it breaks at dropped kerbs and crossing points, and a lot of registers end up storing it as a separate line or even a polygon layer because footway width and surfacing material change block by block in ways a simple centerline can't capture. A shared-use path, a footway that widens into a public square, a stretch with no kerb separation at all, these get awkward fast if you try to force them into the carriageway's data structure.

Treat them as one network and you inherit problems from both directions. Carriageway hierarchy thresholds (traffic volume, strategic function) don't mean anything applied to a footway. Footway hierarchy, which runs on pedestrian usage and location rather than vehicle class, doesn't map back onto a carriageway record either. Keep them split and each layer can carry the attributes its own standard actually asks for.

Different failure modes, different inspection regimes

A carriageway defect register is built around rutting, cracking, potholes, and ride quality, mostly things a vehicle feels. A footway defect register is built around trip hazards: raised or lipped joints, cross-fall, localized subsidence at utility reinstatements. The intervention levels in most authorities' codes are measured in millimetres of lip height for footways and millimetres of rut depth for carriageways; they're not interchangeable numbers even when they sound similar.

That split carries through to inspection frequency too. A Hierarchy 1 carriageway and a Hierarchy 1a footway in the same corridor can sit on completely different inspection cycles, because the risk being managed, high-speed traffic versus pedestrian footing, is a different kind of risk. If your register stores carriageway and footway as one blended "road surface" feature, you lose the ability to schedule either inspection correctly, and you'll end up either over-inspecting the carriageway or under-inspecting the footway to make one cycle fit both.

Parking bays and road markings sit in their own smaller boxes for the same reason. A marking's condition (retroreflectivity, wear) has nothing to do with the carriageway surface underneath it, and a parking bay's extent often needs to be queried independently for enforcement or utilisation work. Lump everything into one "carriageway" polygon and you can't answer a simple question like "how many metres of double yellow line do we have in Hierarchy 2" without manual digging.

Getting the split without two separate surveys

None of this is a reason to run two field programmes. A single pass over current overhead imagery can resolve carriageway edge-of-metal, footway extent, marking lines and parking bays as distinct GIS feature classes in the same delivery, which is the approach behind the register we build from VHR imagery. You still load the hierarchy codes and condition data your own Code of Practice requires; the geometry just arrives already split the way your schema expects, rather than as one blended surface layer a technician has to cut apart by hand.

If your register currently stores carriageway and footway as variants of the same feature, the fix isn't a bigger table. It's two tables, linked by location, each carrying only the attributes its own inspection regime needs.

Curious whether your existing register could use a feature-class cleanup alongside the next imagery refresh? That's exactly what Road Asset Inventory is built to deliver.