gdf_to_nx only uses first and last points of geometry (LineStrings)

[nlaws-camus]

LineStrings can contain more than two points but the _generate_primal method used in gdf_to_nx only parses the first and last points:

momepy/momepy/utils.py

Lines 75 to 77 in 2fda11e

	for row in gdf_network.itertuples():
	first = row.geometry.coords[0]
	last = row.geometry.coords[-1]

Instead, _generate_primal should loop through row.geometry.coords[0:-1] and graph.add_edge for each value, e.g.

key = 0
for row in gdf_network.itertuples():
    data = list(row)[1:]
    attributes = dict(zip(fields, data))
    for i, first in enumerate(row.geometry.coords[0:-1]):
        last = row.geometry.coords[i+1]
        if multigraph:
            graph.add_edge(first, last, key=key, **attributes)
            key += 1
  
            if oneway_column:
                oneway = bool(getattr(row, oneway_column))
                if not oneway:
                    graph.add_edge(last, first, key=key, **attributes)
                    key += 1
          else:
              graph.add_edge(first, last, **attributes)

[martinfleis]

No, it should not.

What we're doing here is transforming a representation of a network where each LineString encodes a portion of, for example, road network between two logical nodes, i.e. junctions. This portion may be straight or super curvy but it is still one portion (I am intentionally avoiding the word segment), which shall be represented in a graph as a single edge between two nodes. The geometry itself is stored as an edge attribute so it is not lost.

Your proposal creates a different graph. One that does not encode logical portions of a network into a graph but one that encodes the way someone has drawn the geometry. You can have a curve composed of 10 segments of LineString or 100 or even 1000 if you want to have a really smooth shape. Each of those encodes the same part of a road network, so each should be a single edge between two nodes. While in your case, you would end up with vastly different graphs encoding different relationships between physical elements. Moreover, you would have a ton of nodes of a degree 2 which are often considered superfluous (but that depends on the type of a graph of course).

I can imagine that a graph you seek may have some use cases but those are unlikely within the scope of momepy.

Happy to hear the use case and why you think what we do is wrong in there, though.

[nlaws-camus]

No problem. My use case is mostly using NetworkX capabilities on the Graph that comes from gdf_to_nx. So edges that have only the first and last nodes is not useful (for example when graphing, using shortest_path_length, and so on).

[wxinl]

I wonder how the gdf_to_nx function deals with intersection of linestrings, like in this image, linestrings from OSM cross each other so there would be a intersection. However, the intersection is neither the starting nor the ending node of the linestring. While in the graph sense, there should be a node there, would gdf_to_nx catch that?

[jGaboardi]

Are those truly intersections? In a network/graph, an intersection by definition is created at nodes (endpoints).

[wxinl]

But when routing at graph, wouldn't we want turnover on these intersections if they could reduce travel time (cost)?

[knaaptime]

it depends on how the actual road works. If that's an overpass, for example, it is not guaranteed to be an intersection (or therefore a node)

[martinfleis]

Yeah. momepy inherits topology of geometry and does all it can not to alter it. So if there's supposed to be an intersection but the linestrings do not end there, there will be no intersection in the graph. Similarly if there is an overpass but, as a result of some operation, the lines end there, momepy will create a node even though there's none.

You just need to ensure the geometry is topologically representing the network prior conversion.

[wxinl]

I see, thank you for the clarification