Different databases using different ways to export xml file

Question

I tried to use different ways to get road osmid database, for same region. The bounding box of that region with north latitude, south latitude, east longitude, west longitude are equal to 30.7302492849 30.6552968187 104.127065029 104.039651731 (in WGS84 system) respectively.

1st approach: export .xml file (name it as map) from "https://www.openstreetmap.org/export (use Overpass API)", install "https://github.com/pgRouting/osm2pgrouting", create postgresql database using the command

osm2pgrouting --f map --conf /usr/share/osm2pgrouting/mapconfig.xml --dbname road_network --username postgres --password *** --addnodes --clean

In the created database, there are 2 tables (at least from name) that I think might contains all the roads in that region, one table named osm_ways, which is an empty table, the other table named ways, which is a table with 3682 lines.

2nd approach: use osmnx.core.graph_from_bbox function in python package osmnx to get map and corresponding database, the database contains 4665 lines.

Not alone the 2 databases have different lines, some road osm id in table in 1st approach can't be found in database in 2nd approach. I thought since this 2 approaches both use openstreetmap on same region, and also will all updated if openstreetmap updated, they should get exact same database. Can someone tell me why is this the case?

Answer 1

2nd approach: use osmnx.core.graph_from_bbox function in python package osmnx to get map and corresponding database, the database contains 4665 lines.

OSMnx does not natively produce database output. It constructs in-memory graphs of OpenStreetMap data from the Overpass API or from a .osm file. You can then save these graphs as shapefiles, GraphML files, node/edge lists, etc.

If by "lines" you mean graph edges, then yes it is possible (in fact, to be expected) that OSMnx would produce a different graph than simply loading raw OSM data into Postgres. You did not provide a minimal working code example to see how you did it, but the graph_from_bbox function you cite has several arguments that impact how many edges you end up with.

For example, the simplify argument can drastically alter how many edges you end up with (and how their OSM IDs are handled/conflated). Similarly impactful are arguments like clean_periphery, truncate_by_edge, retain_all, network_type, etc. The function's parameterization determines how many and what types of edges you get in the end.