search

kuanb / peartree

peartree: A library for converting transit data into a directed graph for sketch network analysis.
MIT License
201 stars 23 forks source link

In walk links logic, do no exempt - include nodes to consider #77

Open kuanb opened 6 years ago

kuanb commented 6 years ago

Code at issue: https://github.com/kuanb/peartree/blob/8ef113bdc5cfaa1fc217fe340b32d69c6ae24eae/peartree/graph.py#L198-L209

Creating an exempt_nodes list causes problems when stacking multiple graphs. Let's say I want to stack one graph on another, and do not want walk networks there. Then, I want to add a 3rd graph, but, this time, I do want to add walk connectors - but just from that new graph to the existing. I have no way of knowing which of the "old" graph nodes to not connect.

So, in this case, it would make more sense to specify which nodes a walk edge should be considered for - not which nodes should not be considered.

yiyange commented 6 years ago

Now I think about it more, it does not seem an issue of choosing using exempt_nodes or the opposite of that. A general flag impute_walk_transfer can only achieve either generating walk transfer between existing graph and new feed or not. and the function is already doing that, even with exempt_nodes.

For the use case like what you mentioned, (actually a concrete case could be assembling different transit operators' cost-based networks, and connector could be a function of transfer cost. So some operators have transfer discount between each other, but some dont. abstractly it is a choice of generating transfer between specified networks, and for the rest, there is no transfer because the cost is high), nodes in the 3rd feed need to be tagged with information such as which network, i.e. operator (1st and 2rd graph have network name in its IDs) it can connect to.

I also wonder, instead of cherrypicking nodes to build/not build connectors, does it have more benefits to build all connectors, and after that assign high cost to specified edges so it is similar to building no connector since it will never be used. I guess that may depend on the application.

kuanb commented 6 years ago

Thanks @yiyange. I think the generation of walk paths should be limited, in either case. The reason is that these are straight line paths. While there is indeed a distance cut off, it seems unnecessary / improper to accurately modeling aspects such as accessibility to add new straight-line paths between lines where there should not be them.

Edges are flagged by type. Perhaps, the best way to do this would be to also limit newly developed edges to nodes that are attached to walk networks and node directly with nodes that are along existing transit networks.

Modeling cross operator transfers is an entirely different feature, in my mind, but definitely one worth developing.