Support all possible values of service periods and exceptions about osm2gtfs HOT 6 OPEN

Working on it, I've noticed some logical problems:

1. What exactly does the following services list with a weekday range and a date range mean:

"services": [
  "Mo-Fr",
  "2017-12-01-2018-02-28"
]

Does it mean:

• inside the date range, the service will run every Monday to Friday?
• the service will always (within start_date and end_date) run on Monday to Friday and inside the date range every day of the week?

2. Also, it is really necessary to support weekdays or weekday ranges inside exceptions? This could easily be expressed by changing the services key. For example:

"services": [
  "Mo-Su"
],
"exceptions": [
  "Sa"
]

could be changed to:

"services": [
  "Mo-Fr",
  "Su"
]

from osm2gtfs.

I therefore would suggest some changes to the Schedule specification:

• depreciate the services key because it's use is confusing
• introduce a new weekdays or days_of_the_week key with a list of weekdays or weekday ranges as value
• introduce a new service_period or dates key with a list of dates or date ranges where date ranges would override the start_date and end_date for this specific line.
• change the exceptions specification to only support date ranges or even only dates (these exceptions could also easily be expressed changing the services key)

What do you think?

from osm2gtfs.

"services": [
  "Mo-Fr",
  "2017-12-01-2018-02-28"
]

This would mean (in ISO terms) that it works Monday to Friday, but in the date range (desember, january, and february) would service daily.

If the purpose of that tagging is to indicate additional service within a date-range, start_date and end_date should be used.

from osm2gtfs.

If the purpose of that tagging is to indicate additional service within a date-range, start_date and end_date should be used.

Yes, you are right, but as for now, start_date and end_date are only possible for the whole schedule.json file, not individual for each line. What do you think of my proposal above?

from osm2gtfs.

@ialokim How is it going with this one? I notice the output currently does not contain exceptions, and I understand it is unresolved due to logic issues?

from osm2gtfs.

First of all, glad to see our little workflow is used for more projects around the globe!

output currently does not contain exceptions

That's true, we didn't agree on a generic approach and I didn't put much time in this project lately.

For what purpose do you want to use the exceptions key exactly? I think part of the problem why we had a hard time defining the exact semantics back then was that we didn't use it at all in our GTFS files. Would my proposal above suit your needs?

from osm2gtfs.