Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timetable Editor, a different way to enter the data #221

Open
skinkie opened this issue Jul 12, 2018 · 2 comments
Open

Timetable Editor, a different way to enter the data #221

skinkie opened this issue Jul 12, 2018 · 2 comments

Comments

@skinkie
Copy link

skinkie commented Jul 12, 2018

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.

image

@landonreed
Copy link
Member

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).

@skinkie
Copy link
Author

skinkie commented Jul 12, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants