How to build a bus stop inventory

A bus stop inventory is a record of every stop your agency serves and everything installed at each one: what it is, where it is, what condition it is in and who is responsible for it. Build it in five steps:

1. Start from the bus stop list in your GTFS feed.
2. Gather the records the agency already has.
3. Decide what to record for each bus stop and each asset.
4. Collect it in the field, one route at a time.
5. Keep it current by updating it whenever someone works at a bus stop.

Start from the bus stops in your GTFS feed

Your GTFS feed's stops.txt file already lists every bus stop with an ID, a name and a location (GTFS Schedule reference). These fields are the most useful starting point:

• stop_id: the identifier the rest of your schedule data uses. Make it the key of the inventory, but first check that it survives a service change: the GTFS best practices ask for persistent IDs, and not every feed has them. Compare two feed versions before you rely on it. If the IDs change, stop_code, the number on the sign, tends to be steadier, since changing it means changing signs.
• stop_code: the number riders see on the sign, if your agency uses one.
• stop_name: usually the street and the cross street.
• stop_lat and stop_lon: the bus stop's location.
• wheelchair_boarding: whether wheelchair boarding is possible, if your feed fills it in.

GTFS tells you where the buses stop, not what is there. The specification has no fields for shelters, benches, lighting or trash cans. In March 2026, transit data experts, including the MBTA's deputy director of transit technology, were working to add amenities to the standard, and the effort was "still in the early stages" (Next City). For now, the amenities are yours to record.

Export the current feed and treat it as the master list, but do not assume every row is right. At one agency I worked for, the feed was consistent. At another, some bus stops were wildly off, in location and in their attributes. Every bus stop the survey finds that is not in the feed, and every stop in the feed that the survey cannot find, is a data-quality finding worth chasing early.

Gather the records you already have

Before anyone goes into the field, collect what the agency already knows. Each source fills in fields the survey would otherwise have to discover, so the survey confirms what is there instead of starting from nothing.

• Contracts. An advertising or maintenance contract may list the shelters it covers, with their locations and sometimes their models and install dates.
• Capital project records. Close-out documents from shelter and bench programs record what was installed where, what it cost and which grant paid for it.
• Purchase records. Orders for benches, trash cans and signs give models, quantities and prices.
• Past work orders and complaints. Even in an old system or an email archive, they show which bus stops have had repairs and which assets keep failing.
• Earlier surveys and photos. A partial inventory from a previous project, or a folder of site photos, is a head start, as long as its date is noted.

Record where each value came from, so the survey team knows what to check and what to trust.

What to record for each bus stop

Keep the bus stop record to what describes the place itself. Assets get records of their own, described in the next section.

• Identity: stop_id, stop_code, stop_name, and the routes that serve the bus stop.
• Position: where the bus stop sits relative to the nearest intersection. TCRP Report 19, the Transportation Research Board's guidelines for the location and design of bus stops, uses three terms: near-side, just before the intersection; far-side, just after it; and midblock, between intersections (TCRP Report 19).
• The boarding area: its surface, its measured length and width, and whether it connects to a sidewalk or a curb ramp. The reference is the pad often called the 5 by 8. Under the DOT's ADA standards, a boarding and alighting area needs a firm, stable surface and, to the extent construction is within the agency's control, a clear length of 96 inches measured perpendicular to the curb and a clear width of 60 inches measured parallel to the roadway (U.S. Access Board, section 810.2). Measure it once, on the survey, and the next sidewalk project or accessibility review can work from the numbers on file.
• Placement notes: why the bus stop sits where it does, such as a driveway, the available right-of-way or a nearby business.
• Lighting: a street light, a light in the shelter, or none.
• Photos: one from the street showing the whole bus stop, one of the sign, and one of each asset, taken from the same angles at every stop so that later photos can be compared with them.

When I surveyed routes, recording a bus stop's location, condition, safety, accessibility and lighting took a few minutes. A bus stop whose placement was in question took longer, and a short note on why a stop is where it is saves the next person from working it out again.

What to record for each asset

Give each asset its own ID, separate from the bus stop's. A shelter can be removed for construction, stored, and installed at a different bus stop. If its record is keyed to the bus stop, its history stays behind when it moves.

For every asset, record:

• its type
• where it is now: a bus stop, or storage
• its install date
• who owns it and who maintains it
• its condition, on a short scale that everyone applies the same way (below), with a photo for anything not in good condition
• its cost and expected life, if you will plan replacements from the inventory (Plan replacements from age and useful life shows how)

Then add the fields that matter for each type. For example:

• Shelter: manufacturer and model, size, whether it carries advertising, lighting, and seating inside.
• Bench: material, length, and whether it is fixed to a pad.
• Real-time display: model, power source, and how it connects.
• Trash can: capacity, and who empties it.

Keep these as fields with fixed choices or dates wherever you can. Free text is how one shelter manufacturer ends up spelled four different ways in the same column, and a filter on any one spelling quietly misses the rest.

Agree on the condition scale before the survey starts, and write down what each level means, so two people rating the same bench give it the same score. For example:

1. Good: works as intended, with no visible damage.
2. Fair: wear or damage that does not affect use.
3. Poor: damage that affects use or safety, and needs a work order.
4. Missing: on record, but not found at the bus stop.

A scale is only worth as much as its definitions. In my experience, when nobody can say what separates one level from the next, such as "good" from "excellent", the ratings lose their value.

Record who is responsible for what

Responsibility at a single bus stop can be split four ways. The agency may own the sign, the pole and some amenities. The city or county may own the sidewalk and the landing pad. An advertising company may own and maintain shelters under contract. And a bus stop on a state highway sits on the state department of transportation's right-of-way. Those contracts can reach further than maintenance. In Halifax, the 15-year shelter advertising contract the municipality signed in 2006 made the advertising company responsible for all shelter maintenance, including glass replacement and snow removal, and it allowed Halifax Transit 45 new shelters over the term, about three a year, before the municipality owed the company extra maintenance costs (The Coast, 2016). Keep a copy of terms like those with the assets they cover.

Record an owner and a maintainer for each asset and for the boarding area, because they are not always the same party. This is the information that sends a complaint to the right place the first time.

Collect it in the field

• Pilot one route first. Survey every bus stop on it, then fix the form before going further. The pilot shows how long a bus stop takes and which fields people read differently.
• Check that surveyors agree. Before the full survey, have each surveyor rate the same handful of bus stops and compare the results. Where their ratings differ, tighten the definitions.
• Survey route by route, in order along each route, so crews do not double back and no bus stop is missed. A bus stop served by several routes is surveyed once, the first time a crew reaches it.
• Use one form, on a phone or tablet, with fixed choices instead of free text wherever possible, and photos that cannot be skipped.
• Check each location on site against the feed's coordinates. The GTFS best practices ask for a bus stop's location to be within four meters of where riders actually board, on the correct side of the street. A point on the wrong side, or across the intersection from the pole, is worth correcting in the feed as well as in the inventory.
• Turn problems into work orders as you go. A damaged panel found during the survey should become a repair request the same day, not a note that waits for the survey to finish.

Keep the bus stop inventory current

An inventory starts going out of date the day the survey ends. It stays current only if the processes that change bus stops also update the inventory.

• Work orders. Every completed work order updates the bus stop or asset it touched: a replaced bench gets a new install date, and a removed shelter moves to storage.
• Service changes. Each new GTFS feed is compared with the inventory: new bus stops get surveyed, and the assets at removed stops are recovered, stored or reassigned.
• Projects. Capital projects and road work that move bus stops or install amenities update the record when the work is finished, not at the end of the year.
• Removals. When an asset is taken out of a bus stop, its record shows where it actually went. In my experience a removed bench or shelter usually went to a warehouse, but when there was no room it could stay in the field for a while, and those were easy to lose track of.

Re-survey on a cycle as well, for example a set of routes each year, to catch what no work order touched.

Where Roote fits

Roote is bus stop asset management software for public transit agencies. Agencies bring their existing bus stops in from GTFS, and the Roote team migrates existing asset data, so the system is useful from the first day. Roote keeps one record for each bus stop and each asset, and agencies define and track their own attributes for both. Change logs are generated from GTFS, and every completed work order, with its close-out photos, lands in the record for its bus stop.