-
Notifications
You must be signed in to change notification settings - Fork 31
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
Source for time data #80
Comments
My repo https://github.com/Skippern/GV-scraper stores the time tables in |
As far as I can see we already have documentation for this one here. But, does it already work, @AltNico? I think it would be good to have a |
You're right, I already have this in the documentation and also a TODO in my trip creator pull request, but like the whole PR it does not work yet.
|
The great work of @AltNico is in this branch: https://github.com/mapanica/osm2gtfs/tree/timetable Currently the code checks in the main class, if the standard creators are used - before the script itself knows about it -, then it enforces the timeline to be parsed, valid and loaded. What about checking only if the file exists and having then the timetable (no matter which format) getting tunneled to the trips creator, which is the one in charge to check parsing errors, etc. I'm happy to provide a patch, but didn't want to do it before asking. |
Yes, this looks a bit strange and should be improved. If this is called |
|
Maybe |
It is and I like it most. However, potentially it can be mixed up with the transitfeed's |
I thought of that as well and agree. However, I think it fits better for our use-case than the transifeed object. Maybe we should rename the latter (in our code) to |
Based on the input here, I filed a pull request #91 proposed for approval. |
This has been merged in #91. Thanks everybody! |
Currently, this repository includes different implementations for cities. Particularly the trip_creators are very much exclusively targeted and programmed for a special data source. However for any new person coming to this script it is almost impossible to find out where to get those data sources, in order to run osm2gtfs with the existing implementations, for example for the sake of testing. As they are so heavily connected, the data (source) on the schedule should be provided, too.
Instead of adding the actual data, I'd suggest to include a
source
field to the configuration file where a valid url to the file containing the time information should be specified. The script would then download the data, save it into thedata
directory and use it. Probably also an argument (similar to the--refresh-
ones should be implemented, e.g.--refresh-time-table
).The text was updated successfully, but these errors were encountered: