Open bridwell opened 10 years ago
This could be a useful feature. In some ways though, its just a matter of operationalizing "accessibility to something".
e.g. in household LCMs its access to jobs thats important, in employment LCMs its access to labor thats important—so its just a matter of defining the POIs in the opposite direction rather than defining access in the opposite direction… right? At least, that’s the way that i’ve been overcoming the issue when applying pandana in my own work.
But maybe i’m oversimplifying, and Scott’s method would yield different results
__ Elijah Knaap PhD Assistant | Coordinator, Spatial Research Lab National Center for Smart Growth Research & Education University of Maryland Dept. Urban Studies and Planning knaaptime@gmail.com | 301.246.0210 | knaaptime.com
On Fri, Nov 14, 2014 at 1:36 PM, scott bridwell notifications@github.com wrote:
So now, the aggregation queries identify the accessibility of a given location (node) by summarizing the properties of locations (other nodes) that can be reached from from the given location within some maximum impedance.It would be nice to mirror this and also be able to identify how accessible a given location is to other locations, i.e. what other locations can reach (traveling to) a given location within a maximum impedance. The choice of a direction is probably model specific. For household location choice models we might be more inclined to use the accessibility from a given location as is available now, but for job location choice models we might care more how about accessible the location is to other locations. In many cases this might be equivalent but for congested networks this could be an issue.
I guess this could be achieved now by simply swapping the from and tonode columns on the edges data frame and creating an additional network. However, it might be nice to eventually enhance the aggregate method to take a direction argument (moving away from vs. moving towards).
Reply to this email directly or view it on GitHub: https://github.com/synthicity/pandana/issues/32
I think Scott's point that the congested network would be different is correct. Eli, what you say is how I do it too, but you would be using the impedances from the job to the households (which might be uncongested in the AM peak) and you really want the congested skims in the opposite direction. As Scott says, you can flip the edges (by flipping from-to) but the memory cost would be 2x, assuming you need to do it both ways. I can imagine there's probably a way to do it where you only travel backwards on the edges. @jdodyk actually might know if this is possible.
Ok, I understand the problem. I didn’t read Scott’s email carefully enough.
Instead of flipping the edges, though, couldn’t you just add a new impedance column that mirrors the opposite direction (since pandana can handle multiple impedances) to avoid creating multiple networks and memory use?
i.e. assuming, for simplicity, all edges are two-way, edge AB has two impedances, A to B (congested during AM) and B to A (uncongested during AM). To travel backwards on the network, could you assign the “AB" impedance to the “BA” edge?
__ Elijah Knaap PhD Assistant | Coordinator, Spatial Research Lab National Center for Smart Growth Research & Education University of Maryland Dept. Urban Studies and Planning knaaptime@gmail.com | 301.246.0210 | knaaptime.com
On Fri, Nov 14, 2014 at 2:19 PM, Fletcher Foti notifications@github.com wrote:
I think Scott's point that the congested network would be different is correct. Eli, what you say is how I do it too, but you would be using the impedances from the job to the households (which might be uncongested in the AM peak) and you really want the congested skims in the opposite direction. As Scott says, you can flip the edges (by flipping from-to) but the memory cost would be 2x, assuming you need to do it both ways. I can imagine there's probably a way to do it where you only travel backwards on the edges. @jdodyk actually might know if this is possible.
Reply to this email directly or view it on GitHub: https://github.com/synthicity/pandana/issues/32#issuecomment-63115036
(I understand that this is effectively exactly what Scott proposed by flipping the edges, I was just hoping it might be a more efficient data structure)
__ Elijah Knaap PhD Assistant | Coordinator, Spatial Research Lab National Center for Smart Growth Research & Education University of Maryland Dept. Urban Studies and Planning knaaptime@gmail.com | 301.246.0210 | knaaptime.com
On Fri, Nov 14, 2014 at 2:19 PM, Fletcher Foti notifications@github.com wrote:
I think Scott's point that the congested network would be different is correct. Eli, what you say is how I do it too, but you would be using the impedances from the job to the households (which might be uncongested in the AM peak) and you really want the congested skims in the opposite direction. As Scott says, you can flip the edges (by flipping from-to) but the memory cost would be 2x, assuming you need to do it both ways. I can imagine there's probably a way to do it where you only travel backwards on the edges. @jdodyk actually might know if this is possible.
Reply to this email directly or view it on GitHub: https://github.com/synthicity/pandana/issues/32#issuecomment-63115036
I like the suggestion of emulating the travel direction with another impedance column. The only issue might be for true one-way streets that can only be traveled in one direction. But maybe this could be handled by giving them a crazy high impedance for the non-allowed direction. This is probably how I will proceed for now.
So now, the aggregation queries identify the accessibility of a given location (node) by summarizing the properties of locations (other nodes) that can be reached from from the given location within some maximum impedance.It would be nice to mirror this and also be able to identify how accessible a given location is to other locations, i.e. what other locations can reach (traveling to) a given location within a maximum impedance.
The choice of a direction is probably model specific. For household location choice models we might be more inclined to use the accessibility from a given location as is available now, but for job location choice models we might care more how about accessible the location is to other locations. In many cases this might be equivalent but for congested networks this could be an issue.
I guess this could be achieved now by simply swapping the from and tonode columns on the edges data frame and creating an additional network. However, it might be nice to eventually enhance the aggregate method to take a direction argument (moving away from vs. moving towards).