Default implementation for route creation

[xamanu]

The current route creation is very much custom for Florianópolis. After the abstraction work happening in (#9) I'd suggest working on a default implementation for route generation based on OSM's Public Transport Schema 2.

Managua can be a good start as the data quality is very consistent and complying the standard data structure without exceptions.

[grote]

It would be nice, if you could make a list where the current implementation deviates from a proper default.

[xamanu]

This is mainly a placeholder for a task (and a follow up PR to #9). Right now, to keep the #9 PR as small as possible no thinking has been going into this and no default implementation has been defined. This here is the issue to take the task.

Once we finished with the factory structure, we probably want to do some deeper thinking all together how and what to do in a default implementation and how it differs from Fenix code: What we want to move into a default implementation as it is, what we want to improve in Fenix and move over to the default implementation, and what is so particular that it has to live in Fenix.

Here is a very much brainstormy list I can come up with right now.

• Separate routes, stops and trips creation into easy understandable and encapsulated pieces
• I'd prefer to use transitfeed's (routes, stops and trips objects) instead of using parallel data structure between the different steps of creation
• Not using Portuguese language for variable nor function names
• Not using a custom blacklist of routes to exclude
• Minimize the overpass api calls to respect the sever and avoiding errors like overpy.exception.OverpassTooManyRequests
• Not using custom urls related to the regional city

[grote]

Thanks for the list!

Separate routes, stops and trips creation into easy understandable and encapsulated pieces

Definitely!

I'd prefer to use transitfeed's (routes, stops and trips objects) instead of using parallel data structure between the different steps of creation

The downside of this would be that we would make ourselves totally dependent on their classes which might change without further notice. This bit me in the past in another project.

Also, we have no way to extend/change things if we ever need to. I'd be careful with that approach if it is even possible. But maybe I misunderstand. Let's look at this in detail when the time comes.

Not using Portuguese language for variable nor function names

Sure, all these should be moved into the FenixCreators.

Not using a custom blacklist of routes to exclude

I think the fixme tag that we discussed elsewhere should already take care of that.

Minimize the overpass api calls to respect the sever and avoiding errors like overpy.exception.OverpassTooManyRequests

Something I'd love to have your help with!

Not using custom urls related to the regional city

For sure! These should either come from OSM tags (#13) or when that's not suitable maybe there could be a get_route_url() method somewhere. I found it nice for debugging to have a direct link to the route schedule in the script's output.

[xamanu]

Let's handle this also in smaller pieces. I created a new issue to only talk about the data structure #30

[grote]

Btw. my goal is that the fenix creators have as little code as possible and use as much code from the default creators as possible.

Keeping methods in the default creators small and overridable should help with that.

[xamanu]

Route creator default implementation can only happen after #30. Besides the "blacklisted" routes in Fenix logic I see no reason why the default route creator would be different for Fenix.

[xamanu]

We now have a proposal for a standard routes creator.

[xamanu]

Resolved with accepted PR #99