Skip to content
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

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

Open
kuanb opened this issue Jun 6, 2018 · 2 comments
Open

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

kuanb opened this issue Jun 6, 2018 · 2 comments
Assignees
Labels

Comments

@kuanb
Copy link
Owner

kuanb commented Jun 6, 2018

Code at issue:

peartree/peartree/graph.py

Lines 198 to 209 in 8ef113b

# Mutates the G network object
sid_lookup = _add_nodes_and_edges(G, name, stops_df, summary_edge_costs)
# Default to exempt new edges created, unless imputing internal
# walk transfers is requested as well
exempt_nodes = sid_lookup.values()
if impute_walk_transfers:
# In which case, we do not have any exempt nodes
exempt_nodes = []
cross_feed_edges = generate_cross_feed_edges(G, name, stops_df,
exempt_nodes,
connection_threshold)

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.

@kuanb kuanb added the bug label Jun 6, 2018
@kuanb kuanb self-assigned this Jun 6, 2018
@yiyange
Copy link
Collaborator

yiyange commented Jun 6, 2018

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
Copy link
Owner Author

kuanb commented Jun 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants