fscottfoti
commented
10 years ago I should say that we have plans to improve the framework significantly over the next month or two. Basically we would like to make it easier to use, make it fully tested and documented, make is easier to compile and install, and include more test data and examples. One of things I'd also like to do is make graph creation easier, likely using Pandas dataframes for the nodes and edges (Pandas didn't exist when I started the accessibility framework). With that caveat, I'll do my best to answer your questions. (I should say I've used the library extensively - it works as designed, it just isn't as usable as it will be.)
1) Correct. Use positional arguments not the external ids. Here is the script I use to create networks:
https://github.com/fscottfoti/urbanaccess/blob/master/scripts/createnetwork.py
here is where I map ids to positions;
https://github.com/fscottfoti/urbanaccess/blob/master/scripts/createnetwork.py#L102
here is an example of what the output looks like:
http://paris.urbansim.org/data/mccog/mccog_network.jar
2) Yes, directional specific arcs are supported. So if edges are different in each direction specify the edge as from_id, to_id and the correct impedance. A direction that isn't supported should not have an edge.
I should also point you to the high-level interface used by
UrbanSim https://github.com/synthicity/urbansim/blob/master/urbansim/utils/networks.py#L78
which has a flag to automatically convert the edges to two-way edges.
3) No there are no turn impedances at this time. I imagine these have to be dealt with as additional "edges" in the underlying library, but we can create an abstraction at some point to make this easier at the high level.
4) Pseudo edges would be the way to do this right now. In principle the ideal network would include access/egress points from parcels to the network, but we've never encountered a region that had this region-wide. So this could be done with centroid connectors as is typical in travel models (except ours are at the parcel level instead of zone level). This could also be done by projecting each centroid to the nearest edge rather than the nearest intersection, but this hasn't been done yet, either.
By the way, the best high level documentation at this point is the paper I'm trying to get published:
I'm adding this as an issue on github for public knowledge since many people might have this problem, although I received it via email. Per Scott Bridwell at MAG:
If you guys have some time, I have a couple of quick questions on constructing a graph for use with the accessibility module.
1) The wiki states that nodeids argument provided to the pya.createGraph method are not actually used by the accessibility model and that the node ids used by the accessibility are actually indexes of the nodes in the vector/ndarray. So should the node ids assigned to the edges be the indexes from the ndarray also? Or should the edges reference the ids in the nodeids argument?
2) Our transportation network models direction specific costs by using a single arc and then having multiple impedance fields (e.g. AB_NODE, BA_NODE, AB_TIME, BA_TIME) and 1-way arcs have impedances of 0 for the direction they are restricted from. Are direction specific costs supported by pyAccess? If so, do I need to transform this so that a row is created for each arc? For example:
[TABLE OMITTED]
3) Does pyAcess support turn impedances (global or turn specific)?
4) When doing aggregations and routing is the distance of a given parcel to the closest node factored into the accumulations (based on say an assumed travel rate) or does the cost accumulation begin at the node itself? I guess I’m generally asking if off-network costs can be accounted for in developing areas with sparse network coverage or if we would have to create pseudo edges to account for this.