Closed rafapereirabr closed 6 years ago
Thanks for the suggestion. I'm thinking about a load_osmnx_graph
method, though I wouldn't want to roll OSMnx too much into the library as it'd be best to keep these tools modular (this is why Partridge is so nice imo; it's discrete).
Good point, I agree. An alternative would be to give the user the option of pointing to a graph
object built previously with OSMnx . If this object is passed to your function, then peartree would consider the road network as a separate but interconnected layer, creating the edges between the road network and the GTFS stops.
Thinking about this more, I am deciding to close it out. I think this is a functionality that should not be built into Peartree. Just as Peartree can easily stack GTFS networks, so to can it stack other networks. But, it's fairly trivial to do that and I think that that functionality is likely quite custom per individual case. As a result, baking in some method into the library feels like feature creep to me.
Happy to hear counter arguments - but closing for now!
Hi Kuan,
it would be great if the function had an option to include the road network and to consider each transport mode as a separate layer.
For an example on how to do this, @mateoneira has done a great work in the research he conducted for his master thesis. In this script here, Neira didn't have GTFS data, but the important thing is that he used OSMnx and networkx to build a multilayer network where each public transport mode and the road network are separate but interconnected layers.