You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering about adding a conversion function for a momepy street network GeoDataFrame to cityseer compatible networkxMultiGraph .
Here is an initial sketch of what this might look like: momepy_to_cityseer
This would mainly be intended for people who want to:
run street network centralities on larger street networks
calculate network centralities using cityseer's methods which adapt the shortest-path algorithms to work for some situations which aren't necessarily covered by e.g. networkX (e.g. shortest path sidestepping issue)
calculate landuse accessibilities over the street network (weighted and unweighted)
calculate mixed-uses over the street network (weighted and unweighted)
aggregate statistics (e.g. building form metrics from momepy) using the street network as a backbone
I'm curious what your thoughts are on things to take into account so that this is useful, e.g.
would there be use cases where people might want to do a round-trip - e.g. momepyGeoDataFrame to cityseer then back to momepy? If so, the edge ids would need to be chained through. The drawback to a round-trip is that network cleaning or decomposition can't be done without losing the association.
the current conversion function doesn't take primal or dual into account, it just builds a network from the edges. This is probably a non-issue unless doing a round-trip as people can simply manipulate the graphs either end depending on what they want to do.
would there be more interest in going straight from a GeoDataFrame or would there be cases where it is better to go from a momepy formatted networkxGraph?
There are probably other things but that's all that comes to mind for now...
The text was updated successfully, but these errors were encountered:
This would certainly be useful. I would probably also be keen to replace networkx with cityseer as an engine for some of our functions internally.
would there be use cases where people might want to do a round-trip
I suppose so.
would there be more interest in going straight from a GeoDataFrame or would there be cases where it is better to go from a momepy formatted networkx Graph
That doesn't matter much imho. GeoDataFrame is the primary structure so having I/O with that is probably better than going via Graph.
Added a io.nx_from_generic_geopandas method which can ingest LineStringGeoPandas data frames and covert them to networkX graphs with geom attributes on the edges. This works for ingesting most LineStringDataFrames but let me know if it would help to have a io.nx_from_momepy_geopandas method with custom logic for momepy.
How different is cityseer-compatible graph from that created with momepy.gdf_to_nx? If we want to optionally depend on cityseer to do centralities, which I think we want, we would need to go from the graph to cityseer structure rather than from geodataframe. Otherwise we'd need to convert graph to geodataframe to create graph again.
@martinfleis
I'm wondering about adding a conversion function for a
momepy
street networkGeoDataFrame
tocityseer
compatiblenetworkx
MultiGraph
.Here is an initial sketch of what this might look like: momepy_to_cityseer
This would mainly be intended for people who want to:
networkX
(e.g. shortest path sidestepping issue)momepy
) using the street network as a backboneI'm curious what your thoughts are on things to take into account so that this is useful, e.g.
momepy
GeoDataFrame
tocityseer
then back tomomepy
? If so, the edge ids would need to be chained through. The drawback to a round-trip is that network cleaning or decomposition can't be done without losing the association.GeoDataFrame
or would there be cases where it is better to go from amomepy
formattednetworkx
Graph
?There are probably other things but that's all that comes to mind for now...
The text was updated successfully, but these errors were encountered: