GTFS Data Requirements for eTransit Timetables

eTransit uses your GTFS data to generate digital timetables, maps, and trip planners. To ensure accurate and user-friendly outputs, your data must follow the requirements below.

✅ 1. Stop Times Must Be Sequential and Valid

• Every trip in stop_times.txt must have a logically increasing stop_sequence.
• Sequences must reflect the actual order of stops the vehicle visits.
• Do not reuse the same stop_sequence within a trip or skip numbers arbitrarily.

Why it matters: eTransit uses stop sequence to build a global stop order. If a trip has sequences out of order, the timetable may show stops in reverse or illogical order.

✅ 2. Stops Should Be Reused Consistently

• Use the same stop_id for the same physical stop location across all trips.
• Avoid creating duplicate stop records for the same location under different IDs unless they truly represent different physical stops (e.g., different platforms).

Why it matters: eTransit builds a unified stop list per route. Duplicate stop IDs can result in broken timetables or mismatched data on maps and stop pages.

✅ 3. Timepoints Must Be Properly Flagged

• Use timepoint = 1 for scheduled stops and timepoint = 0 for interpolated times in stop_times.txt.
• Include all stops (not just timepoints) for full display, but ensure timepoints are correctly marked for rider confidence.

Why it matters: Timepoints appear with emphasis in the timetable. Incorrect flags can confuse riders and misrepresent guaranteed service.

✅ 4. Headsigns Must Be Unique for Route + Direction + Stop Pattern

eTransit groups trips based on their route_id, direction_id, and trip_headsign. Each combination must correspond to a consistent set of stops.

❌ Problem Example:

These trips follow different paths but share the same headsign. This causes eTransit to incorrectly merge stops into one timetable.

✅ Recommended Fix:

• Downtown via A
• Downtown via C
• Downtown (North Branch)
• Downtown (Route A1)

Why it matters: Trips grouped under the same headsign are rendered into a single timetable column set. Reusing headsigns for different stop patterns leads to confusing or broken outputs.

✅ 5. Loop Routes Must Be Defined Carefully

• If a trip ends where it starts (e.g., A → B → C → A), ensure stop sequences clearly reflect the loop's progression.
• Avoid combining multiple loops in a single trip unless intentional.
• Use consistent logic for where a loop "ends" for rider visibility.

Why it matters: Loops without clearly defined sequences or ends can create misleading timetable and map outputs. eTransit supports loops — but needs correct sequences.

✅ 6. No Conflicting Stop Sequences Across Trips

• If two trips have the same set of stops but appear in conflicting sequences, this is considered invalid.
• All trips within a group (Route + Direction + Headsign) must follow the same general stop order.

Why it matters: Conflicting sequences cause the global stop order to break, producing misaligned trip columns and incorrect timetables.

✅ 7. Duplicate Stops in a Trip Are Allowed, But Must Be Logical

• A trip can stop at the same stop_id more than once (e.g., A → B → C → A).
• Ensure these repeated stops have valid sequences and time progression.

Why it matters: eTransit handles repeated stops correctly if stop_sequence and time values are logical and increasing.

✅ 8. Use Clean and Consistent Stop Naming

• Use consistent capitalization, spacing, and abbreviations in stop_name fields.
• Avoid unnecessary punctuation or inconsistent naming conventions.

Why it matters: Clean naming improves readability and searchability for riders in the web interface and printed materials.

✅ Optional (but Recommended) Enhancements

• Use shape_dist_traveled in stop_times.txt for better trip drawing.
• Include route_long_name and route_desc for detailed service pages.
• Keep calendar.txt and calendar_dates.txt updated for accurate day-based filtering.