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

Aggregation query directionality #32

Open
bridwell opened this issue Nov 14, 2014 · 5 comments
Open

Aggregation query directionality #32

bridwell opened this issue Nov 14, 2014 · 5 comments

Comments

@bridwell
Copy link

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).

@knaaptime
Copy link

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:
#32

@fscottfoti
Copy link
Contributor

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.

@knaaptime
Copy link

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:
#32 (comment)

@knaaptime
Copy link

(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:
#32 (comment)

@bridwell
Copy link
Author

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.

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

No branches or pull requests

4 participants