Palos Verdes Peninsula Transit Authority (PVPTA)

Top things to fix

Trillium produces and hosts this feed as a service. These changes are made on their side: send the fix list to your Trillium contact and they apply it and republish.

Score by category

Over time

Overall score across the last 9 checks — down 0.4 since 2026-07-08.

What changed since your last check

• Correctness— no change
• Freshness▼ down 1.7
• Rider experience— no change

What changed in this feed

Overall score fell 0.4 points since 2026-07-08.

Same feed file as 2026-07-08; the published zip did not change.

Subscribe to this feed’s changes (Atom) to hear about grade drops in a reader, with no sign-up.

What changed over time

On 2026-06-30 this feed started at grade D. On 2026-07-04 the grade moved from D to F. On 2026-07-04 it cleared big_gap_in_service, fast_travel_between_consecutive_stops. As of 2026-07-09 it holds grade F.

A plain-language history of this feed, newest first.

• 2026-07-04 Grade went D to F, freshness fell 68 points.

Everything we checked

• Error9 instances

  Trip distance exceeds shape distance (flagged by the MobilityData validator).

  See the linked rule for what this affects.

  Fix: Review the rule documentation for 'trip_distance_exceeds_shape_distance' at https://gtfs-validator.mobilitydata.org/rules.html and check the flagged rows in your feed. (Varies.)

  Validator rule: trip_distance_exceeds_shape_distance · See MobilityData GTFS Validator rules (opens the validator rules on an external site)

• Warning351 instances

  Stop too far from shape using user distance (flagged by the MobilityData validator).

  See the linked rule for what this affects.

  Fix: Review the rule documentation for 'stop_too_far_from_shape_using_user_distance' at https://gtfs-validator.mobilitydata.org/rules.html and check the flagged rows in your feed. (Varies.)

  Agencies here usually clear this within about 1 week (based on 6 observed fixes).

  Validator rule: stop_too_far_from_shape_using_user_distance · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)

• Warning188 instances

  188 of 188 stops don't say whether a wheelchair user can board there.

  Riders who use wheelchairs can't plan a trip when accessibility is marked 'unknown'; apps show no information at all.

  Fix: Set wheelchair_boarding to 1 (accessible) or 2 (not accessible) for every stop. A field survey can start with the busiest stops. (A column in stops.txt; your scheduling software likely has it.)

  Validator rule: scorecard_wheelchair_boarding_unknown · Read the fix guide · See GTFS Schedule reference (opens the GTFS Schedule reference on an external site)

• Warning41 instances

  41 of 41 trips don't say whether the vehicle is wheelchair accessible.

  Even with accessible stops, riders need to know the bus itself can take them.

  Fix: Set wheelchair_accessible on every trip (most small-agency fleets are 100% accessible, so this is often a single default). (Often one default setting in your export.)

  Agencies here usually clear this within about 1 week (based on 5 observed fixes).

  Validator rule: scorecard_wheelchair_accessible_unknown · Read the fix guide · See GTFS Schedule reference (opens the GTFS Schedule reference on an external site)

• Warning30 instances

  Trip distance exceeds shape distance below threshold (flagged by the MobilityData validator).

  See the linked rule for what this affects.

  Fix: Review the rule documentation for 'trip_distance_exceeds_shape_distance_below_threshold' at https://gtfs-validator.mobilitydata.org/rules.html and check the flagged rows in your feed. (Varies.)

  Validator rule: trip_distance_exceeds_shape_distance_below_threshold · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)

• Warning11 instances

  11 of 41 trips have no headsign.

  Riders at the stop can't tell which direction a bus is going.

  Fix: Populate trip_headsign to match what the bus displays. (Usually a bulk edit in your scheduling software.)

  Validator rule: scorecard_missing_headsigns · Read the fix guide · See GTFS Best Practices (opens GTFS Best Practices on an external site)

• Warning1 instance

  This feed's service calendar runs out within the next 30 days.

  If a new feed isn't published before it ends, trip planners will drop your agency and riders will see no service.

  Fix: Schedule a feed re-export now so the new calendar is live well before the current one ends. (Usually a re-export from your scheduling software.)

  Agencies here usually clear this within about 1 week (based on 24 observed fixes).

  Validator rule: feed_expiration_date30_days · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)

• Warning1 instance

  Route short name too long (flagged by the MobilityData validator).

  See the linked rule for what this affects.

  Fix: Review the rule documentation for 'route_short_name_too_long' at https://gtfs-validator.mobilitydata.org/rules.html and check the flagged rows in your feed. (Varies.)

  Validator rule: route_short_name_too_long · See MobilityData GTFS Validator rules (opens the validator rules on an external site)

• Warning1 instance

  Many of the feed's trips don't run at all in the next 7 days.

  It usually means old service periods are still in the export, making the feed bigger and harder to check.

  Fix: Trim past service periods the next time you export. (One setting in most export tools.)

  Agencies here usually clear this within about 1 week (based on 31 observed fixes).

  Validator rule: trip_coverage_not_active_for_next7_days · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)

• Warning1 instance

  Service data runs out in 14 day(s).

  When the calendar runs out, trip planners stop showing this agency. Fixing it now is calmer than after riders notice.

  Fix: Re-export with a validity window that reaches at least 60 days out. (One export setting.)

  Agencies here usually clear this within about 1 week (based on 61 observed fixes).

  Validator rule: scorecard_feed_expiring_soon · Read the fix guide · See GTFS Best Practices (opens GTFS Best Practices on an external site)

• Warning1 instance

  The feed contains no fare information.

  Riders see 'fare unknown' in trip planners and can't budget their trip; visitors are most affected.

  Fix: 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. (A small file for most flat-fare systems.)

  Validator rule: scorecard_no_fare_data · Read the fix guide · See GTFS Best Practices (opens GTFS Best Practices on an external site)

Beyond the grade

Opportunities that do not change your grade today: fare detail, on-demand service, and deeper accessibility data.

• 2 route badge(s) pair a color and text color below the WCAG 4.5:1 contrast bar (Green Eastview, Orange).

  Consider: Adjust route_color or route_text_color so each pair clears 4.5:1. Often switching the text between black and white is enough.

• 153 stop name(s) use abbreviations or symbols a screen reader may mispronounce, with no spoken form set ("Miraleste Dr & Via Colinita", "Western Ave & Park Plaza", "Western Ave & Trudi", and more).

  Consider: Add tts_stop_name with the spoken form, e.g. 'Main Street and Second Avenue', for the affected stops.

Some fixes we can make for you

These are the safe mechanical fixes, applied to a copy of your feed. They change only what is certain and leave everything else untouched. Review the diff before you publish.

• Recased shouting stop names 2 changes

  For example: PVPHS -> Pvphs

Run it yourself on your own copy of the feed: scorecard autofix <feed.zip> --out corrected.zip