First feedback

[nilsnolde]

I tried it now for a graph spanning all of Austria:

1. generate the topology with osm2po: java -Xmx2g -jar osm2po-core-5.3.2-signed.jar cmd=c prefix=austria austria-latest.osm.pbf
2. load the resulting sql: psql -U postgres -W -h localhost -d gis_test -f austria/austria_2po_4pgr.sql
3. 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?

[mbasa]

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 ***@***.***> wrote: I tried it now for a graph spanning all of Austria: 1. generate the topology with osm2po: java -Xmx2g -jar osm2po-core-5.3.2-signed.jar cmd=c prefix=austria austria-latest.osm.pbf 2. load the resulting sql: psql -U postgres -W -h localhost -d gis_test -f austria/austria_2po_4pgr.sql 3. 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 <#3>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADRAJF66FE7FZYOAENHPQTS4QK45ANCNFSM4W2LU44A> .

[mbasa]

Tokyo to Nagasaki city.

…

On Sun, Jan 31, 2021 at 0:04 Mario Basa ***@***.***> 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 ***@***.***> wrote: > I tried it now for a graph spanning all of Austria: > > 1. generate the topology with osm2po: java -Xmx2g -jar > osm2po-core-5.3.2-signed.jar cmd=c prefix=austria austria-latest.osm.pbf > 2. load the resulting sql: psql -U postgres -W -h localhost -d > gis_test -f austria/austria_2po_4pgr.sql > 3. 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 > <#3>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADRAJF66FE7FZYOAENHPQTS4QK45ANCNFSM4W2LU44A> > . >

[nilsnolde]

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

[mbasa]

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

[mbasa]

and I did this just to be sure that all the proper statistics of the table are updated:
vacuum full austria_2po_4pgr;

[mbasa]

[nilsnolde]

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 🤦

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:)

[mbasa]

Having fun playing around with the Austrian data. This 342 km route from somewhere around Salzburg to Wien took 0.3 sec.

[nilsnolde]

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?

[mbasa]

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.

[nilsnolde]

Aaah great find! That sounds muuuch better:) Will try that as well this week!