-
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
Refactor OsmHelper #31
Comments
Looks nice! Where are the methods to refresh a route (and maybe even a stop)? Is this I was passing the routes into get_stops() and sometimes chaining these calls, because there's no point getting a stop if it is not part of a route relation, right? Also, you when you refresh a route, this might add new stops that you didn't have before. The same applies when you refresh a route master, you might get a new route variant and new stops. |
Refresh routes, stops and single route would happen through
The function I think it's better to handle stops independently of routes. I can think about several reasons for this:
For the case when a route refresh comes up with new stops that are not cached already, I introduced the I generally would like to handle all OSM specific things inside OsmHelper. This means, applied to routes, that from outside (of OsmHelper) there only exist routes (like in GTFS). All RouteMaster and RouteVariant stuff is handled inside the helper. When you refresh a route OsmHelper checks the master relation and route variants for it to be refreshed. |
Alright, sounds good. The cache refresh method is a matter of taste. If we might want to refresh different things in the future, I would agree with the parameter approach, but there will never be more than stops and routes. The arbitrary parameters you need to to error handling and offload to independent methods anyway. So I'd say using dedicated refresh methods is cleaner. |
Yes, indeed, it's a matter of taste. I don't really care. Let's look how it looks like when we implement it. The only addition to refresh I can think of right now, is what you said above: refresh a single stop. |
Refactored with the latest commit. Documenting here the changes and closing the issue.
Implemented the following structure: OsmConnector
|
The OsmHelper is the part of the script that retrieves data from OpenStreetMap and puts it into the own class/object data structure (to be) discussed in #30. It has included a simple caching functionality that saves data obtained from OpenStreetMap into files and grabs them, if present, to avoid unnecessary hits to the OSM's Overpass API.
I think the current structure of the OsmHelper can be improved and I'm doing a very first draft here, so we have a base for discussion:
OsmHelper
Some thoughts:
The text was updated successfully, but these errors were encountered: