Add networkx conversion from momepy street network?

[songololo]

@martinfleis

I'm wondering about adding a conversion function for a momepy street network GeoDataFrame to cityseer compatible networkx 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:

• 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. momepy GeoDataFrame 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 networkx Graph?

There are probably other things but that's all that comes to mind for now...

[martinfleis]

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.

cc @jGaboardi

[songololo]

Added a io.nx_from_generic_geopandas method which can ingest LineString GeoPandas data frames and covert them to networkX graphs with geom attributes on the edges. This works for ingesting most LineString DataFrames but let me know if it would help to have a io.nx_from_momepy_geopandas method with custom logic for momepy.

Example added at momepy_to_cityseer.ipynb.

[martinfleis]

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.

[songololo]

Hi @martinfleis

I am experimenting with a new API which may address your question from before. This would only work with the latest beta version tagged 4.25.0b2. It completely skips the NetworkX and uses a faster conversion between GeoPandas and the underlying Rust-optimised network structures. At the moment, the below example is roughly how the API is intended to work.

EDIT - It is also possible to go straight from NetworkX if that is preferred or well-known text format. Not sure what the typical workflow is for you, but happy to look at this further.

# %% [markdown]
# # CityNetwork API
# Requires v4.25.0b2
# Demonstrates the new class-based `CityNetwork` API using the momepy Bubenec sample dataset.
# 

# %% [markdown]
# ## Load momepy sample data
# 

# %%
import geopandas as gpd
import momepy

# Load the Bubenec streets dataset (EPSG:3857, projected)
streets = gpd.read_file(momepy.datasets.get_path("bubenec"), layer="streets")
print("Streets:", len(streets))
print("CRS:", streets.crs)
streets.head()

# %% [markdown]
# ## Build a CityNetwork from the GeoDataFrame
# 
# `CityNetwork.from_geopandas` accepts any GeoDataFrame of LineString geometries with a projected CRS.
# 

# %%
from cityseer.network import CityNetwork

cn = CityNetwork.from_geopandas(streets)
print(cn)

# %% [markdown]
# ## Compute centralities
# 

# %%
distances = [200, 400, 800]

cn.centrality_shortest(distances=distances)
cn.centrality_simplest(distances=distances)

cn.nodes_gdf.head()

# %% [markdown]
# ## Plot results
# 

# %%
import matplotlib.pyplot as plt

bg_colour = "#111"
text_colour = "#ddd"
edges_result = cn.to_geopandas()
live_edges = edges_result[edges_result["live"]].copy()

for d in distances:
    fig, axes = plt.subplots(1, 2, figsize=(10, 5), dpi=150, facecolor=bg_colour)
    fig.suptitle(f"Bubenec — {d}m", fontsize=10, color=text_colour)

    for ax in axes:
        ax.set_facecolor(bg_colour)
        ax.set_axis_off()

    live_edges.plot(
        column=f"cc_harmonic_{d}",
        ax=axes[0],
        cmap="magma",
        linewidth=0.3,
        legend=False,
    )
    axes[0].set_title("Harmonic closeness (shortest)", fontsize=7, color=text_colour)

    live_edges.plot(
        column=f"cc_betweenness_{d}",
        ax=axes[1],
        cmap="magma",
        linewidth=0.3,
        legend=False,
    )
    axes[1].set_title("Betweenness (shortest)", fontsize=7, color=text_colour)

    plt.tight_layout()
    plt.show()

# %% [markdown]
# ## Export to GeoDataFrame
# 

# %%
# Export back to GeoDataFrame with original edge geometries and computed metrics
result_gdf = cn.to_geopandas()
print(result_gdf.columns.tolist())
result_gdf.head()

[martinfleis]

This looks neat!

Though if I wanted to ship computation of centrality to cityseer from within momepy, I would ideally do the conversion from and to networkx graph. The way I envisage it is that the API would remain the same as is now (see https://docs.momepy.org/en/stable/api/momepy.closeness_centrality.html) only with an additional keyword engine="cityseer" or engine="networkx". So under the hood, we'd need to convert the graph to CityNetwork and then convert that back.

[songololo]

Hey Martin, thanks for your feedback.

I've bumped the demo version to 4.25.0b3 - which is what the attached notebook requires.

The idea is that new API would work with either GeoPandas or NetworkX. So it could ingest the NetworkX graph directly.

Something to be aware of: internally, it converts the input graph to a dual representation, so it is actually calculating the centralities relative to edges, and then it unpacks this onto the original street edges. The reason it uses streets is because this works more intuitively for visualisation and also for angular centralities.

Whether computing shortest or simplest versions, by default, they will compute for both closeness and betweenness variants; however, these can be toggled on or off as a function argument it preferred.

city_network_momepy.ipynb

import geopandas as gpd
import matplotlib.pyplot as plt
import momepy

from cityseer.network import CityNetwork

# Load momepy sample data and convert to NetworkX
streets = gpd.read_file(momepy.datasets.get_path("bubenec"), layer="streets")
G = momepy.gdf_to_nx(streets)
print(f"Input graph: {G.number_of_nodes()} nodes, {G.number_of_edges()} edges")

# Build network and compute centrality
distances = [200, 400, 800]
cn = CityNetwork.from_nx(G)
cn.centrality_shortest(distances=distances)
cn.centrality_simplest(distances=distances)

# Round-trip: returns a copy of G with cc_ columns on each edge
G_result = cn.to_nx()
print(f"Output graph: {G_result.number_of_nodes()} nodes, {G_result.number_of_edges()} edges")

# Verify original attrs preserved and centrality added
sample = list(G_result.edges(data=True, keys=True))[0]
print(f"Edge attrs: {sorted(sample[3].keys())}")

# Plot via momepy's nx_to_gdf
edges_gdf = momepy.nx_to_gdf(G_result, points=False)
bg, fg = "#111", "#ddd"
fig, axes = plt.subplots(2, 2, figsize=(10, 10), dpi=150, facecolor=bg)
fig.suptitle("Bubenec — 800m (NetworkX round-trip)", fontsize=10, color=fg)
for ax in axes.flat:
    ax.set_facecolor(bg)
    ax.set_axis_off()
edges_gdf.plot(column="cc_harmonic_800", ax=axes[0, 0], cmap="magma", linewidth=0.3, legend=False)
axes[0, 0].set_title("Harmonic closeness (shortest)", fontsize=7, color=fg)
edges_gdf.plot(column="cc_betweenness_800", ax=axes[0, 1], cmap="magma", linewidth=0.3, legend=False)
axes[0, 1].set_title("Betweenness (shortest)", fontsize=7, color=fg)
edges_gdf.plot(column="cc_harmonic_800_ang", ax=axes[1, 0], cmap="magma", linewidth=0.3, legend=False)
axes[1, 0].set_title("Harmonic closeness (simplest)", fontsize=7, color=fg)
edges_gdf.plot(column="cc_betweenness_800_ang", ax=axes[1, 1], cmap="magma", linewidth=0.3, legend=False)
axes[1, 1].set_title("Betweenness (simplest)", fontsize=7, color=fg)
plt.tight_layout()
plt.show()

[martinfleis]

Is it more efficient to compute all closeness and betweenness (including various bandwidths) all together, than doing it it one by one?

internally, it converts the input graph to a dual representation, so it is actually calculating the centralities relative to edges

I'll need to play with it. While it is not consistent with networkx, it is typically what people want. I just need to figure out how to pipe it to momepy to avoid unexpected behaviour.

[songololo]

Is it more efficient to compute all closeness and betweenness (including various bandwidths) all together, than doing it it one by one?

Yes, it can share the same Dijkstra shortest path tree traversal across multiple distances and methods when combining them. That said, they can also be done one at a time if preferred.

Heads up that it now also has an experimental opt-in sampling strategy for larger distance thresholds, so it's relatively manageable even at large distances on large city networks.

[songololo]

PS - Draft docs for the new API - https://cityseer-api-docs--pr171-dev-xusg12r0.web.app/api/network