AttributeError: 'float' object has no attribute 'add_node'

[rxl204]

Hi, I am getting the above error when setting impute_walk_transfers to True in pt.load_feed_as_graph. I am able to construct the graph with just (feed, start, end), but unable to when including impute_walk_transfer. I want to incorporate bus to bus transfer and bus to subway transfer as well as walking edges in my network. Is this the right way to achieve that?

[kuanb]

Hi @rxl204 and apologies for the delayed response. It seems like you are attempting to do something reasonable that peartree ought to handle. Could you provide:

• A snippet of your code that I could use to reproduce your error?
• A traceback of the error would be helpful, as well.
• If you have the gtfs feed that you are using, making that available would also be useful.

Thanks!

[kuanb]

I have not heard back from you but I did want to provide some examples and thoughts that might assist you in the future.

Re: Questions about the impute_walk_transfer flag First, I would not typically turn on the impute_walk_transfers on your first GTFS load. That is, if you are loading in one GTFS feed, you do not need to turn this flag on as any transfers possible ought to be encoded in the GTFS feed itself. This flag makes the most sense to turn on when you are stacking feeds on top of one another.

For example, let's say you are in the Bay Area and you want to better capture/model connections between AC Transit (a service provider in the East Bay) and BART (the regional rail service provider throughout the Bay). In this example, using the impute_walk_transfers flag would allow you to capture the timed transfers and other intentional connections between the two systems that are lost when each publishes their own GTFS feed.

Here's an example of New Orleans' transit network when parsed from their published feed*:

And here's the result of the same, but with the impute_walk_transfers flag turned on:

While this is just the diagrammatic overview, the general point is that there is no significant/noticeable change between the two.

Re: Incorporating walk networks I wrote the following walk through if you are interested in using OpenStreetMap walk data to layer that information on top of transit data to get a stacked walk + transit network: http://kuanbutts.com/2018/12/24/peartree-with-walk-network/

Perhaps you may find it useful in identifying patterns for how to user peartree to stack a walk network on a transit network.

*How I parsed the NOLA transit network:

import peartree as pt

path = 'nola_gtfs.zip'

# Automatically identify the busiest day and
# read that in as a Partidge feed
feed = pt.get_representative_feed(path)

# Set a target time period to
# use to summarize impedance
start = 7*60*60  # 7:00 AM
end = 10*60*60  # 10:00 AM

# Converts feed subset into a directed
# network multigraph
G = pt.load_feed_as_graph(feed, start, end)

[rxl204]

Hi Kuanb,

Sorry for the late reply and thank you for your inputs! I've constructed the network with impute_walk_transfer, but on checking, I found that some of the 'shortest paths' are actually not the shortest. I am wondering if the edges are actually weighted on the wait time/ headway/ transfer and travel time.

Anyway, using the constructed network, I intend to disrupt the network by removing some edges to check how betweenness centrality changes by comparing the delta. I am also combining the traditional measure of betweenness with ridership data to calculate the true betweenness of the network.

For now, I haven't stacked the walk network with the transit network for fear that it will take too long to compute centrality.

On Sat, Jan 12, 2019 at 3:58 AM Kuan Butts notifications@github.com wrote:

I have not heard back from you but I did want to provide some examples and thoughts that might assist you in the future.

Re: Questions about the impute_walk_transfer flag. First, I would not typically turn on the impute_walk_transfers on your first GTFS load. That is, if you are loading in one GTFS feed, you do not need to turn this flag on as any transfers possible ought to be encoded in the GTFS feed itself. This flag makes the most sense to turn on when you are stacking feeds on top of one another.

For example, let's say you are in the Bay Area and you want to better capture/model connections between AC Transit (a service provider in the East Bay) and BART (the regional rail service provider throughout the Bay). In this example, using the impute_walk_transfers flag would allow you to capture the timed transfers and other intentional connections between the two systems that are lost when each publishes their own GTFS feed.

Here's an example of New Orleans' transit network when parsed from their published feed*: [image: image] https://user-images.githubusercontent.com/6053396/51056563-0a16f600-1598-11e9-9797-373bc914e87d.png

And here's the result of the same, but with the impute_walk_transfers flag turned on: [image: image] https://user-images.githubusercontent.com/6053396/51056567-0be0b980-1598-11e9-9a15-7feff3b7c42c.png

While this is just the diagrammatic overview, the general point is that there is no significant/noticeable change between the two.

Re: Incorporating walk networks I wrote the following walk through if you are interested in using OpenStreetMap walk data to layer that information on top of transit data to get a stacked walk + transit network: http://kuanbutts.com/2018/12/24/peartree-with-walk-network/

Perhaps you may find it useful in identifying patterns for how to user peartree to stack a walk network on a transit network.

• How I parsed the NOLA transit network:

import peartree as pt

path = 'nola_gtfs.zip'

Automatically identify the busiest day and

read that in as a Partidge feed

feed = pt.get_representative_feed(path)

Set a target time period to

use to summarize impedance

start = 76060 # 7:00 AM end = 106060 # 10:00 AM

Converts feed subset into a directed

network multigraph

G = pt.load_feed_as_graph(feed, start, end)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kuanb/peartree/issues/123#issuecomment-453637941, or mute the thread https://github.com/notifications/unsubscribe-auth/AeLCPXR-2NbNVYXwJ4zRwG8htasxvo6Mks5vCOzZgaJpZM4ZnpHg .

[kuanb]

Interesting observation regarding shortest paths - can you provide some examples?

In addition, would it be possible to share the transit feed you are working with? You should be able to just drag and drop the file into GitHub in this issue, or you could provide an external link.

Finally, if you are concerned about performance, check out the export to graph tool feature. Once there, weighted betweenness is also easy to calculate. Here's an example blog post covering this:

http://kuanbutts.com/2018/11/19/graph-tool-drive-network-stress-test

Also, here's more discussion on why graph tool is advantageous for this kind of work:

http://kuanbutts.com/2018/08/17/peartree-to-graph-tool/

The docker image provided in the repo should get you up and running with it quickly.

[rxl204]

So the path here is not the usual path recommended, there is a path with 1 transfer, but using shortest path, peartree takes a path with 3 transfers. How can I include the wait and transfer times?

The link to GTFS feed: https://github.com/yinshanyang/singapore-gtfs

I had some difficulty installing graph tool on windows previously, will try it again. Thank you!

[kuanb]

Ah! Thanks for the clarification. So, what happened was that it suggested a path with too many transfers. Right now, the transfer penalty between lines is half the headway.

Without being familiar with that particular route, I suspect that, even with the headways included, the 3 transfer path was "technically" faster given the published GTFS.

To implement a max transfer penalty, you would need to track transfer counts (is the route moving from walk > transit edge and, if so, how many times has this happened).

You could do that by modifying the networkx underlying djikstra implementation, which is pretty short and straightforward. It's exposed here in the networkx code: https://github.com/networkx/networkx/blob/e32425d12b4cc6d20306e00df9211c2ee7ad02d2/networkx/algorithms/shortest_paths/weighted.py#L805-L852

That said, I think your observation is a great point - peartree should implement assistance in this category and offer a method that allows for transfer limits to be established when creating shortest paths.

(I've primarily used this tool to do system-wide accessibility analytics so variation like that in exact shortest paths that were assigned to a given origin-destination pair was deemed acceptable.)

[kuanb]

I created a new issue to track the above feature request: https://github.com/kuanb/peartree/issues/124

[kuanb]

Given that the above issue was created to track the feature request (#124) and the error that was the title of this issue (AttributeError: 'float' object has no attribute 'add_node'), was not able to be produced, even from the shared dataset, and no activity has occurred on this PR for > 1 week, I am going to close out this issue. Please re-open or comment if I failed to assist/address the concern of this issue!