Feed status · checked 2026-09-05
TFI Ferries, Cable Cars and Regional Flights
Based on the official feed source on file
Service mode Bus + Ferry + 2 more
First scorecard for this agency
Catalogued in Ireland.
A data-quality and completeness lens to help an agency improve its GTFS feed. Not an official compliance determination from any transit program. New to this? How to read your scorecard. Interactive view of this scorecard. Rubric v1.3, validator 8.0.1.
Checked for changes 1 hours ago; last changed 1 hours ago.
Measured 3 of 4 score categories from the official feed URL on file.
How we measured this
Confidence in this measurement: medium.
- Realtime quality was not measured this run. It does not count against the grade.
- The feed was downloaded from the official feed URL on file.
Confidence describes how much the pipeline could measure this run, not the feed itself. It never changes the grade.
Top things to fix
Set wheelchair_boarding to 1 (accessible) or 2 (not accessible) for every stop. A field survey can start with the busiest stops.Likely your team
60 of 60 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.
⏱ A column in stops.txt; your scheduling software likely has it.worth about +25 points in its category
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.
⏱ A small file for most flat-fare systems.worth about +15 points in its category
Only change the flagged IDs if an app needs basic ASCII values. Update each place that uses the ID. Keep all names and headsigns in their original language.
Some internal IDs use characters outside the basic text set. These IDs are valid UTF-8 data. This warning is only about support in older apps. It does not mean that names in other languages are wrong.
⏱ A planned ID change, not a quick text cleanup.worth about +8 points in its category
Finding handoff
Move one finding to a recheck
Select one finding. Copy the request, make the change in the feed-producing tool, then compare the next complete run.
- Feed evidence
- 60 of 60 stops don't say whether a wheelchair user can board there.
- Next action
- Set wheelchair_boarding to 1 (accessible) or 2 (not accessible) for every stop. A field survey can start with the busiest stops.
- Recheck
- Publish the changed feed at the same URL. On the next complete, comparable scorecard run, confirm that this finding is no longer reported.
Copy handoff text
- Feed evidence
- The feed contains no fare information.
- Next action
- 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.
- Recheck
- Publish the changed feed at the same URL. On the next complete, comparable scorecard run, confirm that this finding is no longer reported.
Copy handoff text
- Feed evidence
- Some internal IDs use characters outside the basic text set.
- Next action
- Only change the flagged IDs if an app needs basic ASCII values. Update each place that uses the ID. Keep all names and headsigns in their original language.
- Recheck
- Publish the changed feed at the same URL. On the next complete, comparable scorecard run, confirm that this finding is no longer reported.
Copy handoff text
How to make and check these changes
Check the result on the published feed. Read the guide, make the change in your tool, and use the next comparable run to see whether the finding is still reported. Only an action or ticket record can attribute who made the change.
Set wheelchair_boarding to 1 (accessible) or 2 (not accessible) for every stop. A field survey can start with the busiest stops. · Read the fix guide
Make the change. Make this change in whatever tool produces your feed, then re-export.
Check the result. The next scorecard run checks this finding again. If a comparable check no longer reports it, the feed's clearance log records that result. This confirms feed state, not who made the change. Self-check a feed before you publish.
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. · Read the fix guide
Make the change. Make this change in whatever tool produces your feed, then re-export.
Check the result. The next scorecard run checks this finding again. If a comparable check no longer reports it, the feed's clearance log records that result. This confirms feed state, not who made the change. Self-check a feed before you publish.
Only change the flagged IDs if an app needs basic ASCII values. Update each place that uses the ID. Keep all names and headsigns in their original language.
Make the change. Make this change in whatever tool produces your feed, then re-export.
Check the result. The next scorecard run checks this finding again. If a comparable check no longer reports it, the feed's clearance log records that result. This confirms feed state, not who made the change. Self-check a feed before you publish.
Rider view: what this feed publishes
A quick read of rider-facing information in this feed.
- Schedule visibility
- The feed's last published service date is in 482 days.
- Published accessibility data
- Accessibility information is stated for 0% of stops and 100% of trips. This measures published data, not whether stops or vehicles are physically usable.
- Fare information
- No fare information is published in the feed.
- Realtime information
- Realtime-feed availability and live-arrival coverage are not known from this scorecard.
Important: This does not rate service reliability. Riders should confirm current service alerts, fares, and accessibility accommodations with the transit operator before traveling.
Ungraded capability read
Ferry data profile
A ferry-specific view of what this GTFS feed publishes. Schedule measurements use ferry routes and trips only; fare and realtime facts are labelled as whole-feed. Unknown values are not treated as no.
- Ferry service
- 32 routes · 8,290 trips
- Terminal structure
- 50 ferry boarding locations; no parent-station hierarchy is published.
- Terminal access
- Not applicable: no ferry boarding location is linked to a parent station, so stop_access is not permitted here.
- Published accessibility
- Unknown: none of the 50 ferry boarding locations publish wheelchair_boarding. 100% of ferry trips publish a value; 100% of all ferry trips explicitly say allowed (8,290 of 8,290). Unstated values remain unknown. This reports published values, not verified physical usability.
- Bicycles
- 100% of ferry trips publish a value; 59.4% of all ferry trips explicitly say allowed (4,921 of 8,290). Unstated values remain unknown.
- Cars
- Unknown: none of the 8,290 ferry trips publish cars_allowed.
- Fares
- Whole feed: no applied fare data is published. This is not evidence that ferry service is free.
- Realtime
- Whole feed: no GTFS-Realtime endpoints are configured in this scorecard.
Descriptive only. This profile does not change the grade or verify vessels, terminal facilities, vehicle carriage, fares, or accessibility in the real world. Field meanings follow the GTFS Schedule reference.
Send your vendor a fix request
You may not control the GTFS export yourself. Copy this and send it to whoever runs your scheduling software export. It names each fix with the validator notice and a guide link.
Score by category
The MobilityData validator flagged 7 kinds of issue across 10123 instances (0 error, 644 warning, 9479 informational).
Service data covers the next 482 days.
0% of stops state wheelchair accessibility (0% marked accessible, 0% marked not accessible). This measures what the feed publishes, not whether a stop is physically usable. Fare data is not published.
0% of stops state accessibility (0% marked accessible). Reflects what the feed states, not verified physical usability.
Not scored yet. Nothing here counts against the grade.
Routes and stops
Each route is drawn once, using the longest shape its trips follow; stops are the dots.
This feed has 60 stops.
The route and stop data is ready below. Load the map only when you want the geographic view. It uses additional data.
Basemap: OpenFreeMap, © OpenStreetMap contributors. Routes and stops: this agency's GTFS feed.
- Cable (brown)
- EI3401 (green)
- EI3402 (green)
- EI3403 (green)
- EI3408 (green)
- FL1 (green)
- FL2 (green)
- FL3 (green)
- FR5306 (green)
- FR5307 (green)
- FR611 (green)
- FR612 (green)
- FY12 (teal)
- FY17 (teal)
- FY18 (teal)
- FY20 (teal)
- FY22 (teal)
- FY24 (teal)
- FY26 (teal)
- FY27 (teal)
- FY30 (teal)
- FY35 (teal)
- FY36 (teal)
- FY37 (teal)
- FY40 (teal)
- FY41 (teal)
- FY42 (teal)
- FY43 (teal)
- FY45 (teal)
- FY48 (teal)
- FY50 (teal)
- FY55 (teal)
- FY60 (teal)
- FY62 (teal)
- FY65 (teal)
- FY66 (teal)
- FY68 (teal)
- FY70 (teal)
- FY71 (teal)
- FY73 (teal)
- FY75 (teal)
- FY76 (teal)
- FY80 (teal)
- FY85 (teal)
| Route | Type | Line color |
|---|---|---|
| Cable Ballaghboy - Dursey Island | Aerial lift | brown |
| EI3401 Dún na nGall - Dublin | Transit line | green |
| EI3402 Dublin - Dún na nGall | Transit line | green |
| EI3403 Dún na nGall - Dublin | Transit line | green |
| EI3408 Dublin - Dún na nGall | Transit line | green |
| FL1 Conamara - Inis Mór | Transit line | green |
| FL2 Conamara - Inis Meáin | Transit line | green |
| FL3 Conamara - Inis Oírr | Transit line | green |
| FR5306 Dublin - Kerry | Transit line | green |
| FR5307 Kerry - Dublin | Transit line | green |
| FR611 Dublin - Kerry | Transit line | green |
| FR612 Kerry - Dublin | Transit line | green |
| FY12 Strangford - Portaferry | Ferry | teal |
| FY17 Ballycastle - Rathlin Island | Ferry | teal |
| FY18 Ballycastle - Rathlin Island | Ferry | teal |
| FY20 Magilligan Point - Greencastle | Ferry | teal |
| FY22 Buncrana - Rathmullan | Ferry | teal |
| FY24 Machaire Uí Rabhartaigh - Toraigh | Ferry | teal |
| FY26 Ailt an Chorráin - Árainn Mhór | Ferry | teal |
| FY27 Ailt an Chorráin - Árainn Mhór | Ferry | teal |
| FY30 Doran's Point - Inis Bigil | Ferry | teal |
| FY35 Roonah Pier - Clare Island | Ferry | teal |
| FY36 Roonah Pier - Clare Island | Ferry | teal |
| FY37 Roonah Pier - Inishturk | Ferry | teal |
| FY40 Cleggan - Inishbofin | Ferry | teal |
| FY41 Ros an Mhíl - Inis Mór | Ferry | teal |
| FY42 Ros an Mhíl - Inis Meáin | Ferry | teal |
| FY43 Ros an Mhíl - Inis Oírr | Ferry | teal |
| FY45 Galway Docks - Inis Mór | Ferry | teal |
| FY48 Doolin - Inis Mór | Ferry | teal |
| FY50 Killimer - Tarbert | Ferry | teal |
| FY55 Reenard Point - Knightstown | Ferry | teal |
| FY60 Castletownbere - Bere Island West | Ferry | teal |
| FY62 The Pontoon - Bere Island East | Ferry | teal |
| FY65 Blue Pool - Garinish Island | Ferry | teal |
| FY66 Glengarriff Pier - Garinish Island | Ferry | teal |
| FY68 Bantry - Whiddy Island | Ferry | teal |
| FY70 Colla Pier - Long Island | Ferry | teal |
| FY71 Schull - Cléire | Ferry | teal |
| FY73 Cunnamore Pier - Heir Island | Ferry | teal |
| FY75 Baltimore - Cléire | Ferry | teal |
| FY76 Baltimore - Sherkin Island | Ferry | teal |
| FY80 Glenbrook - Carrigaloe | Ferry | teal |
| FY85 Passage East - Ballyhack | Ferry | teal |
| KY10 TFI Anseo Killarney | Bus | green (no shape in feed) |
| LK1 TFI Anseo Limerick | Bus | green (no shape in feed) |
| MY1 TFI Anseo Achill | Bus | green (no shape in feed) |
List every stop
- Magilligan Point
- Ballycastle
- Rathlin Island
- Strangford
- Portaferry
- Dublin Airport Terminal 2
- Dublin Airport Terminal 1
- Ballyhack
- Killimer
- Doolin Pier
- Glenbrook
- Carrigaloe
- Whiddy Island
- Bantry
- Castletownbere
- Bere Island West
- Baltimore
- Sherkin Island
- The Pontoon
- Bere Island East
- Blue Pool
- Glengarriff Pier
- Garinish Island
- Colla Pier
- Long Island
- Schull
- Cunnamore Pier
- Heir Island
- Cléire
- Ballaghboy
- Dursey Island
- Tarbert
- Reenard Point
- Knightstown
- Kerry Airport
- Passage East
- Galway Docks
- Inis Mór
- Inis Meáin
- Inis Oírr
- Ros an Mhíl
- Cleggan
- Inishbofin
- Aerfort Chonamara
- Aeradróm Inis Mór
- Aeradróm Inis Meáin
- Aeradróm Inis Oírr
- Roonah Pier
- Clare Island
- Doran's Point
- Inis Bigil
- Inishturk
- Greencastle
- Toraigh
- Machaire Uí Rabhartaigh
- Ailt an Chorráin
- Árainn Mhór
- Buncrana
- Rathmullan
- Donegal Airport
Over time
This is the first scorecard for this agency. A trend and a "what changed" summary appear here once it has been checked more than once.
Everything we checked
10 findings, ordered by severity.
Show every finding
- Warning479 instances
Some internal IDs use characters outside the basic text set.
These IDs are valid UTF-8 data. This warning is only about support in older apps. It does not mean that names in other languages are wrong.
Fix: Only change the flagged IDs if an app needs basic ASCII values. Update each place that uses the ID. Keep all names and headsigns in their original language. (A planned ID change, not a quick text cleanup.)
Finding code: non_ascii_or_non_printable_char · See MobilityData GTFS Validator rules (opens the validator rules on an external site)
- Warning77 instances
Some scheduled trips move faster between stops than a transit vehicle can.
Usually a typo'd stop time; riders get arrival times no transit vehicle can meet.
Fix: Check the flagged stop times for transposed minutes. (A few minutes per flagged trip.)
Finding code: fast_travel_between_consecutive_stops · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)
- Warning77 instances
Between two distant stops, the times imply a speed no transit vehicle reaches.
A rider gets a trip plan that cannot happen. Live systems then report delays that are not real.
Fix: Check the two stop times for a wrong digit first. Then check whether a stop sits at the wrong coordinates, or a stop between them is missing. (Minutes per flagged trip once you open it.)
Finding code: fast_travel_between_far_stops · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)
- Warning60 instances
60 of 60 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.)
Finding code: scorecard_wheelchair_boarding_unknown · Read the fix guide · See GTFS Schedule reference (opens the GTFS Schedule reference on an external site)
- Warning11 instances
Unexpected enum value (flagged by the MobilityData validator).
See the linked rule for what this affects.
Fix: Review the rule documentation for 'unexpected_enum_value' at https://gtfs-validator.mobilitydata.org/rules.html and check the flagged rows in your feed. (Varies.)
Finding code: unexpected_enum_value · See MobilityData GTFS Validator rules (opens the validator rules 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.)
Finding code: scorecard_no_fare_data · Read the fix guide · See GTFS Best Practices (opens GTFS Best Practices on an external site)
- Info9025 instances
Unsorted stop times (flagged by the MobilityData validator).
See the linked rule for what this affects.
Fix: Review the rule documentation for 'unsorted_stop_times' at https://gtfs-validator.mobilitydata.org/rules.html and check the flagged rows in your feed. (Varies.)
Finding code: unsorted_stop_times · See MobilityData GTFS Validator rules (opens the validator rules on an external site)
- Info452 instances
The feed has a stretch of two weeks or more with no service running.
A long gap can mean dates were left out of the calendar. Apps then show no trips on those days.
Fix: Check whether the gap is real, like a seasonal break; if not, add the missing dates to the calendar. (A review of your calendar dates.)
Finding code: big_gap_in_service · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)
- Info2 instances
Some files contain columns that are not part of the GTFS spec.
Harmless to riders, but apps ignore these columns and they can hide typos in real column names.
Fix: Check the flagged column names for misspellings of standard GTFS fields; remove them if they are vendor extras. (A quick look at the flagged files.)
Finding code: unknown_column · Read the fix guide · See MobilityData GTFS Validator rules (opens the validator rules on an external site)
- Info1 instance
This feed includes flexible (demand-responsive) service, and riders are told how to book it.
Dial-a-ride and zone service are described for trip planners, not just fixed routes.
Fix: No action needed. (None.)
Finding code: scorecard_flex_service
Conformance mark Not yet
One requirement remains for this feed to earn the conformance mark. States wheelchair access on 0% of stops and 100% of trips; the mark needs 90% of each.
- Valid Met
- Passes validation with no errors.
- Current Met
- Service data covers the next 482 days.
- Accessible Not yet
- States wheelchair access on 0% of stops and 100% of trips; the mark needs 90% of each.
In plain words: earn this mark when your feed passes validation, has not expired, and says whether nearly every stop and trip is wheelchair accessible.
A pass credential for a feed that is valid, current, and states wheelchair access on nearly every stop and trip. Accessibility here measures what the feed publishes, not whether a stop is physically usable. How the conformance mark works.
Clears the Google and Apple Maps four-week coverage bar. This feed has 482 days of service ahead, clearing the four-week (28-day) window Maps asks for. No validator errors either, so riders keep seeing this agency in their trip planners; warnings lower the grade here but do not remove a feed from Maps.
How this agency maps to the standards
The scorecard is a data-quality lens, not a compliance determination. Its universal references describe good GTFS and useful rider information. Useful references here are GTFS Schedule Best Practices, GTFS-Realtime Best Practices, MobilityData grading scheme, Google Transit publication guidance. Read the full standards crosswalk.
- Correctness 68 / 100
- GTFS Schedule best practices, checked by the MobilityData validator. MobilityData grading covers stop locations, route names, and colors. Google Transit requires a feed to pass validation for publication.
- Freshness 100 / 100
- GTFS Schedule best practices call for a dataset that stays current. An expired calendar can remove service from Google Transit and other rider trip planners.
- Rider experience 60 / 100
- GTFS Best Practices for rider-facing fields. MobilityData grading covers stop names and headsigns.
- Realtime quality Not yet published
- GTFS-Realtime best practices: a stable URL, high uptime, and frequent updates.
Show your grade
Put a badge on your agency site or feed README. It updates after each completed scoring check and links back to this scorecard.
Prefer a shields.io style? Point a dynamic endpoint badge at the published badge.json.
Cite this record
This page updates on every check. The record below does not: it is the dated file this grade came from, published at https://gtfsscorecard.org/data/artifacts/tfi-ferries-cable-flights/2026-09-05.json and never overwritten, pinning the grade, category scores, rubric version, validator version, reader archive profile, and the scored feed's sha256 as they stood on 2026-09-05. Use it in a board packet, a regulatory filing, or a research citation instead of linking the live page, whose content will differ on your next visit.
Citing the tool itself rather than one agency's record? Use the repo's CITATION.cff.