Durango Transit

What this grade measures

The quality of the schedule data in the feed scored here for trip-planning apps: whether riders using Google Maps, Apple Maps, or Transit see current, correct, and complete information. It measures the data feed, not service quality or operations.

Progress this period

No newly cleared items this period. The score and trend above reflect where the feed stands today.

What needs attention next

Three improvements, in priority order, each sized so the board can see what it is approving:

1. Add fare_attributes.txt (or Fares v2 files) with your fare structure. If your service is fare-free, ask to have it marked fare-free instead.

   The feed contains no fare information. Riders see 'fare unknown' in trip planners and can't budget their trip; visitors are most affected.

   This one is about the feed as a whole, so there is no share of it to count.

   Estimated effort: A small file for most flat-fare systems.

2. Check the stop order and the shape direction in your scheduling software; the shape is often drawn backwards.

   On some trips the stops fall along the route line in a different order than the schedule lists. Trip planners can draw the bus doubling back or skipping ahead, which confuses riders reading the map.

   This is a validator notice, and the validator decides what each instance covers, so no share of the network can be read from it here.

   Estimated effort: A few minutes per flagged trip.

3. Add feed_contact_email or feed_contact_url to feed_info.txt.

   feed_info.txt lists no contact email and no contact URL. Without a contact, apps like Google Maps can't reach you when they find a problem in the feed.

   This is a validator notice, and the validator decides what each instance covers, so no share of the network can be read from it here.

   Estimated effort: One field, set once in export settings.