Closed jucardwell closed 3 months ago
Sorry @jucardwell that this issue slipped through the gaps for such a long time :scream:. The resolution to your problem is that "edge_id" values only mean something within one single graph, and should never be used to compare graphs. The fact that the first example generates identical edge id values should be considered an accident. (This case will only arise when graph contraction produces the exact format required for representation as sf
LINESTRING objects, which is not always the case.)
Hi @mpadge, thanks for the response. Just for clarification, the node_ids should remain consistent?
Yes, they're directly from OSM.
Hi,
I am working on a project that requires me to remove road segments based on a set of lat/lons. To do so, I exported a weighted streetnet as an sf object so that I could identify the appropriate segments to remove using spatial queries.
I had initially done testing using the built-in hampi streetnet to ensure that the edge_ids remain consistent between the contracted graph and the sf object, and I determined that they were. For instance, in the case below, both tests return TRUE only
However, when trying to remove the edges from my own network, I discovered that they actually did not remain consistent. Subsequently I discovered that when using a weighting profile, edge_ids no longer remain consistent between the contracted graph and the sf object. For instance, in the case below, both tests return TRUE and FALSE
However, it seems that when even using a weighting profile, the from_id and to_id remain consistent