Open nilsnolde opened 3 years ago
Nils,
Will try using the Austria data tomorrow. Like I mentioned before, I was able to use the entire road network of Japan with 9 million edges, and I was getting results in milliseconds for searches within 100 km. A search from Tokyo to Nagasaki, which has a distance of around 1,200 km, resulted in 6 seconds. So I'm curious now why the Austria data will take so long.
Btw, thanks a lot for the PR. I'm testing it right now and will merge right afterwards.
On Sat, Jan 30, 2021 at 23:40 Nils notifications@github.com wrote:
I tried it now for a graph spanning all of Austria:
- generate the topology with osm2po: java -Xmx2g -jar osm2po-core-5.3.2-signed.jar cmd=c prefix=austria austria-latest.osm.pbf
- load the resulting sql: psql -U postgres -W -h localhost -d gis_test -f austria/austria_2po_4pgr.sql
- create the view following the README: CREATE VIEW pgrserver AS SELECT id,source,target,cost,geom_way AS geom FROM austria_2po_4pgr ;
That leads to:
- 1.7 Mio (bidirectional) edges
- ~ 2 GB RAM base graph
- ~ 40 seconds to load the graph from PG
That I'm actually quite happy with, good performance, bit too much RAM maybe.
When I try to query even short distances I get an empty response (tried Dijkstra, AStar, CH). If I actually try from on end of Austria to the other (Vienna -> Liechtenstein), CH is running for 10 minutes at > 7 GB RAM on 8 threads before I canceled.
However, small extracts (I tried Sydney real quick) with the same workflow works well!
Did you ever try a bigger graph?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mbasa/pgrServer/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADRAJF66FE7FZYOAENHPQTS4QK45ANCNFSM4W2LU44A .
Tokyo to Nagasaki city.
On Sun, Jan 31, 2021 at 0:04 Mario Basa mario.basa@gmail.com wrote:
Nils,
Will try using the Austria data tomorrow. Like I mentioned before, I was able to use the entire road network of Japan with 9 million edges, and I was getting results in milliseconds for searches within 100 km. A search from Tokyo to Nagasaki, which has a distance of around 1,200 km, resulted in 6 seconds. So I'm curious now why the Austria data will take so long.
Btw, thanks a lot for the PR. I'm testing it right now and will merge right afterwards.
On Sat, Jan 30, 2021 at 23:40 Nils notifications@github.com wrote:
I tried it now for a graph spanning all of Austria:
- generate the topology with osm2po: java -Xmx2g -jar osm2po-core-5.3.2-signed.jar cmd=c prefix=austria austria-latest.osm.pbf
- load the resulting sql: psql -U postgres -W -h localhost -d gis_test -f austria/austria_2po_4pgr.sql
- create the view following the README: CREATE VIEW pgrserver AS SELECT id,source,target,cost,geom_way AS geom FROM austria_2po_4pgr ;
That leads to:
- 1.7 Mio (bidirectional) edges
- ~ 2 GB RAM base graph
- ~ 40 seconds to load the graph from PG
That I'm actually quite happy with, good performance, bit too much RAM maybe.
When I try to query even short distances I get an empty response (tried Dijkstra, AStar, CH). If I actually try from on end of Austria to the other (Vienna -> Liechtenstein), CH is running for 10 minutes at > 7 GB RAM on 8 threads before I canceled.
However, small extracts (I tried Sydney real quick) with the same workflow works well!
Did you ever try a bigger graph?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mbasa/pgrServer/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADRAJF66FE7FZYOAENHPQTS4QK45ANCNFSM4W2LU44A .
Right, should've the email again! I'm not 100% that I didn't do a mistake there. Though Sydney working suggests that the workflow should generally be fine.
BTW, the osm2po needs a modification since a few versions in its config or it won't give back a pgrouting compatible sql file: https://gis.stackexchange.com/questions/175428/how-to-make-osm2po-5-1-write-an-sql-file
Can you ensure that there is an index on the geometry field. My indexes look like this:
Indexes:
"pkey_austria_2po_4pgr" PRIMARY KEY, btree (id)
"austria_geom_ndx" gist (geom_way)
"idx_austria_2po_4pgr_source" btree (source)
"idx_austria_2po_4pgr_target" btree (target)
With a Dijkstra search:
time curl -X GET "http://localhost:8080/pgrServer/api/latlng/dijkstra?source_x=13.8791641&source_y=48.236348&target_x=13.8986078&target_y=48.2311891" -H "accept: application/json"
I am getting these result times :
real 0m0.036s
user 0m0.009s
sys 0m0.009s
and I did this just to be sure that all the proper statistics of the table are updated:
vacuum full austria_2po_4pgr;
Uff, yeah sorry, no spatial index, rookie mistake.. just wanted to propose to put that in the readme for rookies like me but it's right there already :facepalm:
gis_test=# select pg_size_pretty(pg_relation_size('austria_geom_ndx'));
pg_size_pretty
----------------
99 MB
(1 row)
Just building CH for the first time. Will report back how that went:)
Having fun playing around with the Austrian data. This 342 km route from somewhere around Salzburg to Wien took 0.3 sec.
Nice performance!
I had to cancel CH building after 3 hours, was foolish to try it out locally. Will try again on a server when it's idle enough. There's no way (yet) to preserve it on disk after it built I guess?
osm2po
creates very small cost values which confuses some of the search algorithms, especially the chbDijkstra. I suggest creating the pgrserver view this way:
create view pgrserver as select id,source,target,cost * 3600 as cost,geom_way as geom from switzerland_2po_4pgr ;
With this, the initial call to chbDIjkstra took only 40 seconds using the Swiss data, and a subsequent 400 km search took just 0.2 seconds to complete.
Aaah great find! That sounds muuuch better:) Will try that as well this week!
I tried it now for a graph spanning all of Austria:
java -Xmx2g -jar osm2po-core-5.3.2-signed.jar cmd=c prefix=austria austria-latest.osm.pbf
psql -U postgres -W -h localhost -d gis_test -f austria/austria_2po_4pgr.sql
CREATE VIEW pgrserver AS SELECT id,source,target,cost,geom_way AS geom FROM austria_2po_4pgr ;
That leads to:
That I'm actually quite happy with, good performance, bit too much RAM maybe.
When I try to query even short distances I get an empty response (tried Dijkstra, AStar, CH). If I actually try from on end of Austria to the other (Vienna -> Liechtenstein), CH is running for 10 minutes at > 7 GB RAM on 8 threads before I canceled.
However, small extracts (I tried Sydney real quick) with the same workflow works well!
Did you ever try a bigger graph?