Add network_type argument to add_osm_feature (or do it a different way)

[Robinlovelace]

I think there is are advantages of having this in osmdata instead of other pkgs such as dodgr.

I've thought about this before, but am finally opening opening this issue after trying:

import networkx as nx
import osmnx as ox
import requests
import matplotlib.cm as cm
import matplotlib.colors as colors
# after fixing a couple of issues, e.g. with https://github.com/gboeing/osmnx/issues/45 and:
# Error in py_call_impl(callable, dots$args, dots$keywords) : 
#   ImportError: Something is wrong with the numpy installation. While importing we detected an older version of numpy in ['/home/robin/.local/lib/python3.6/site-packages/numpy']. One method of fixing this is to repeatedly uninstall numpy until none is found, then reinstall this version. 
# ... I can do this:
G = ox.graph_from_place('leeds', network_type='drive')
ox.plot_graph(ox.project_graph(G)) # note this was sloooow!

[Robinlovelace]

Probably a better test network:

G = ox.graph_from_place('isle of wight', network_type='drive')
ox.plot_graph(ox.project_graph(G)) # note this was sloooow!

[Robinlovelace]

But may still be faster than dodgr::dodgr_streetnet() or the equivalent osmdata code (not tested).

[Robinlovelace]

And here's a nice small result from Bangor fyi:

[mpadge]

Great use case. This is definitely the intention of osmdata_sc() -> dodgr. The first part is done, and is generally several times faster to extract than osmdata_sf() (ref issue #148). What I then need to do is convert dodgr to use SC as the base class rather than current specialized dodgr_streetnet class. The entire workflow should then be pretty seamless between network extraction and analysis. I'm happy to keep this issue open until that time (maybe shifting it over to dodgr at some stage?) as a prompt. Thanks!

---

And the big advantage of dodgr over osmnx which we have to push harder is the "dual weighted" aspect - the osmnx -> networkx workflow can still only deal with single-weighted networks, which means either routing can be done properly but distances will be junk (coz they'll only be weighted distances, not real distances) or distances can be done properly but routing won't be realistic (coz the network won't be appropriately weighted). That trade-off is really substantial, and one that only dodgr circumvents at present as far as I know.

[mpadge]

I intend to soon start thinking about this in a structured way in this exploratory repo. I'll update this issue as thoughts and insights progress there ...

[Robinlovelace]

Great. I think overall osmnx and osmdata have different aims, with a main feature of the former being the provision of route network functions like betweenness. In that sense osmdata is more modular. However, I think this feature does not represent feature creep and that this is the ideal place for it because downloading networks usable by different modes is a common need, that could be used downstream by packages like dodgr. Seems that in osmnx the network types are hardcoded: https://github.com/gboeing/osmnx/blob/master/osmnx/core.py#L543

I could have a bash at implementing that, but also exposing the feature type to the user, if you like. One question: where should that live?

[mpadge]

I'll trust your judgment on that one, and correspondingly be happy to integrate in osmdata. It's all implicitly integrated with the new dodgr::weighting_profiles values. It's still just a messy script, but will be in a user-editable form this coming week. But yeah, that presumes that the best or preferred workflow for all users will be osmdata->dodgr, and one ought restrict as far as possible such presumptions. Ergo: I can definitely see the utility of some kind of osm_streetnet() function, which just blanks out all the bits for each mode of transport that have NA weights in the dodgr profiles.