What counts as street furniture on a GIS asset layer?
Ask five people in a county highway department what "street furniture" means and you'll get five different answers, usually right up until someone has to actually populate the attribute table. Then the arguments start: is a mailbox cluster furniture? What about a jersey barrier that's been sitting in the same spot for six years? Is a stop sign furniture, or is it a traffic control device that lives in its own feature class because FHWA wants it tracked separately for MUTCD compliance?
There's no single national standard that settles this for every agency, but most asset registers converge on the same rough boundary, and it's worth writing down before your crew (or your contractor) starts digitizing.
The core street furniture feature class
In practice, "street furniture" on a GIS asset layer usually means fixed, discrete, above-ground objects that sit within the right-of-way but aren't part of the driving or walking surface itself. That's the test: can you drive or walk over it, or does it sit beside the thing you drive or walk over?
Typical items:
- Signs (regulatory, warning, guide, street name)
- Bollards and delineator posts
- Guardrail and barrier segments
- Benches, litter bins, bike racks
- Lighting poles and mast arms
- Utility poles owned by the county rather than the utility company
- Hydrants, where they're tracked on the road layer rather than the water system's own GIS
Each of these gets a point or line feature, an asset ID, install date if known, material, condition rating, and whatever maintenance district code your agency uses for work order routing. Signs usually carry their own sub-schema (MUTCD code, retroreflectivity test date) because FHWA sign assessment rules are stricter than anything else on this list.
Anything that's part of the surface stays out of street furniture by the same logic: the carriageway itself, the footway or sidewalk, pavement markings, and parking bay striping. Those are flat-plan features. They have area or linewidth, not a footprint you'd trip over, and they belong in a pavement or marking feature class with their own attribute set (surface type, width, PCI or condition score, lane configuration).
Why the distinction matters for data collection, not just filing
The boundary changes how the data gets collected, not just where it ends up in the schema. Carriageway edges, footway extents, parking stall striping, and painted markings are all flat, planar, and visible in overhead imagery at a resolution fine enough to trace. That's a photogrammetry problem: trace the polygon, tag the attribute, move on.
Street furniture is a different animal. A sign face, a bollard, a bench. These are small, vertical, and frequently shadowed or occluded by tree canopy and parked vehicles when you're looking straight down. Getting a reliable sign inventory with retroreflectivity readings or a bollard count with material and height generally means a ground-level pass, whether that's a walking crew, a van-mounted camera system, or a mix.
That's the practical reason most agencies run two tracks for register builds: an overhead extraction pass for the surface layers, and a street-level pass for the vertical furniture. Forcing both out of a single capture method usually leaves one half of the register thin.
If your register-build problem right now is the first half, the flat-plan layers that eat the most digitizing hours and go stale fastest between resurveys, that's the piece Road Asset Inventory pulls straight from overhead imagery: carriageway, footway, marking, and parking features delivered as GIS-ready data on a biennial cadence, so you're not paying a walking crew to re-trace the same curb lines every cycle.
Keep your street furniture schema as its own feature class with its own attribute rules. The sign count and the curb line still won't come off the same flight.
Worth a look if the carriageway and parking layers are the part of the register eating your team's time this cycle.