Timetable Editor, a different way to enter the data

[landonreed]

Issue by skinkie
Thursday Jul 12, 2018 at 13:31 GMT
Originally opened as catalogueglobal#221

---

At this moment the entering of the data requires some love see (#216 ) but I think we can make it even better than it currently is. Many publications include a form where availability is described as departing trips given weekdays and weekend and sometimes have a footnote.

In my perspective the ability to just copy, either by copy/paste or data entry an entire schedule and only then add the availability conditions (transmodel) or calendars (gtfs) could greatly improve how the data is entered. So ideally: every trip of all calendars can be observed in a single view additional to the filtering views that is currently implemented per calendar. Then per trip one or more calendars can be added. The system may then suggest an optimal arrangement by denormalising all calendar data, and normalising it back to find the least possible exceptions.

[landonreed]

Comment by landonreed
Thursday Jul 12, 2018 at 18:20 GMT

---

The timetable editor already allows copying and pasting existing data into the editor. However, I have not seen many published timetables that include both weekday and weekend schedules woven into the same view (which I believe is what is pictured above).

There are perhaps optimizations that can be made to the timetable editor, but I'm not entirely sure how intuitive or generalizable it would be apply one or more calendars to sets of trips in a single view. Perhaps this makes quite a bit of sense for certain GTFS feeds, but I'm not sure if trip timings are often shared between different calendars across a wide number of GTFS feeds. I do see how it could be valuable for comparing the frequencies of different calendars, but I'm not sure if the benefits would justify the efforts to redesign this (especially given that the data model we're using only allows a given trip entity to reference a single calendar).

[landonreed]

Comment by skinkie
Thursday Jul 12, 2018 at 18:28 GMT

---

In my perspective the GTFS data model should not be used as the internal datamodel because GTFS does not understand operational periods, like summer, winter, holidays. Better is to allow multiple calendars on a trip, denormalise all data, and normalise it back to GTFS. This makes entering data easy, but also makes it always fully compliant with GTFS.