New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First feedback #3
Comments
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>
.
|
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>
> .
>
|
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: |
Can you ensure that there is an index on the geometry field. My indexes look like this:
With a Dijkstra search:
I am getting these result times :
|
and I did this just to be sure that all the proper statistics of the table are updated: |
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 🤦
Just building CH for the first time. Will report back how that went:) |
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? |
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?
The text was updated successfully, but these errors were encountered: