save_graph_xml enumerates way IDs starting at 0 instead of using the actual OSM ID?

[larsschwarz]

When exporting a graph via save_graph_xml the resulting XML includes nodes in the expected format, but for ways the export just seems to enumerate all ways starting at 0 instead of using the actual OSM ID.

So a Node has the ID attribute like this jus fine

<node id="<actual_osm_id>">

but a Way like this

<way id="<int_starting_at_0++>">

I tried various parameter combinations like setting merge_edges or oneway to True or False, but the output remains the same.

The source graph is generated via

G = ox.graph_from_place(query = place, network_type='all', simplify = False, retain_all=True)

all useful_tags_* settings do have specified the ID explicitly.

When using the exported XML like this for further processing most tools will feature to generate the respective Feature ID (GeoJSON for example). Is there any option to properly include the way ID in the export or can the graph be modified to have way IDs set somehow so save_graph_xml uses them properly?

[gboeing]

The problem is that OSM doesn't represent nodes and ways in a graph-theoretic sense, but OSMnx does represent nodes and edges in a graph-theoretic sense. In other words, ways and edges do not map 1:1 onto each other. A single OSM way could result in multiple graph edges, and a single graph edge could comprise multiple OSM ways (especially when considering graph simplification).

Accordingly, OSMnx does not (and cannot) uniquely identify graph edges by their OSM ID. Rather it uses (u, v, k) identifier triplets via networkx under the hood. To save an XML file, we are saving nodes and edges to disk. To save those edges as ways in the XML file, we cannot use their triplets as the unique ID (due to format expectations), and we cannot use their OSM IDs as the unique ID (due to non-uniqueness among the graph edges). Hence we generate a sequential unique identifier.

[larsschwarz]

I see! Thanks for the explanation. Closing issue.

[gboeing]

Note that this has been fixed and the true way OSM IDs are now used, in #1135

[cristi-zz]

Hi! Thank you for a useful library.
Until 2.0 hits the pypi, is there a workaround for the <way id=0 . . .> situation? The JOSM is throwing a tantrum bc of id=0. My workaround for now is manually editing the XML file and write some large ID.

[gboeing]

I'm hoping to release a 2.0 beta on PyPI in roughly a month. In the meantime you could install the v2 GitHub branch, which is essentially a reasonably well tested alpha at this stage. (I am using it in production myself now.)