Use Custom Pandana Network/Weights

[d-wasserman]

This is definitely an enhancement idea:
It seems that currently the assumption is the street network is pulled from OSM, but there is little stopping it from using an arbitrary pandana network already created. What is the possibility of integrating custom travel networks?

Generally, I think this is possible, but the big concern I have here is you can't set the CRS assumptions for urbanaccess because of its use of the vincenty function from geopy (which will be removed in 2.0 as an FYI). So you will have to set the pandana network to WGS 1984, but we could document that.

Curious what your thoughts on this might be @sablanchard.

I implemented this with the following as a quick draft, and I think it works (same principle as loading OSM, but loading WGS 1984 projected edges/nodes).

def add_custom_network(network_edges,network_nodes,ua_network,chosen_weight="weight",net_type="walk"):
    """This function will integrate a custom set of nodes and edges that is projected to WGS 1984 so that it integrates with an
    urban access network."""
    network_edges['weight'] = network_edges[chosen_weight]
    # assign node and edge net type
    network_edges['net_type'] = net_type
    network_nodes['net_type'] = net_type
    ua_network.osm_nodes = network_nodes
    ua_network.osm_edges = network_edges
    print("Updated urban access network with updated edges and nodes")
    return ua_network ```

[sablanchard]

Hi @d-wasserman,
Yes you are correct there is little modification needed to utilize a custom network instead of the default pedestrian OSM network.

Thanks for the heads up on vincenty, we can update that to use the new recommended function in the next version of UrbanAccess and update the docs to make it clear coordinates need to be WGS84. Added it as new issue here: #53

Yes your code snippet would accomplish what you want without any other modifications to urbanaccess. Essentially you are trying to replicate what happens here: https://github.com/UDST/urbanaccess/blob/dev/urbanaccess/osm/network.py when the OSM network is set to equal the urbanacces OSM network objects so what you have there looks correct.

To generalize this some data validation checks could be placed in that function (as well as data schema additions to docs) to ensure that the custom network can work with other urbanaccess processes down the line without any further modifications. These would include:

The graph network must be a directed graph (e.g. in pandana terminology it must be an explicit oneway network where each edge where two direction travel is possible the edge must occur twice with directionality inferred by the IDs in the to and from columns.)

In terms of the data schema for the resulting network objects:
nodes df:
index: must be named id and a int
id: must be int
net_type: must be string with value walk
x: must be float projected in WGS84
y: must be float projected in WGS84

edges df:
from: must be int
to: must be int
net_type: must be string with value walk
weight: must be travel time as a float in minutes

Long term solution would be to generalize this so that the OSM network is optional so you dont need it and can instead choose to use a custom network like what you have here that has its own set of generalized urbanaccess network objects so its clear in the API. So Ill add this to the development roadmap barring any PRs from anyone who would like to take this on now.

[d-wasserman]

Hi Sam,
That is essentially correct. I borrowed from that assuming you had nodes and edges. Thanks clearer docs are great.

No problem on vincenty. Thought you would like to know.

Agreed on all points. I might be interested in adding a PR including validation if that would help.

One clarification: do you mean minutes instead of seconds for the weight?
osm_edges['weight'] = (osm_edges['distance'] / 1609.34) / travel_speed_mph * 60 implies minutes since distance is the meters value from vincenty, to miles, then divided by 3 mph to hours.

[sablanchard]

Ok sounds good @d-wasserman ! Yes for sure PRs are welcome and we can take a look when its in.

Yes sorry about that, my mixup, it is minutes not seconds. Ill edit the comment.