[pgrouting-users] Re: Fwd: NiuRouting, PgRouting for SQLite

[Jaak Laineste]

> 
>> I think the trick here is to only load the topology for the bbox
>> needed to solve the query. This is what pgRouting does.
> 
> That is one part of the "trick" :)
> 
> I also store my OSM data in SQLite with spatialite
> But I call the trsp algorithm as an external process
> and implemented graph caching there. This increase the
> speed of "incremental" route calulations "inside" the
> same bbox which is the typicial use case in car navigation. 
> 
> Additional I use a bbox filter based on geom data of the "edges"
> which is stored in the DB
> 
> Building the graph is the most time consuming task
> and needs more time then fetching the data from sqlite.
> The bbox filter just reduces the memory consumption

What is the project you're talking about here?

Spatialite Djikstra does not really have any query to fetch the data, where bbox could be applied. My understanding is that:
a) in pgRouting with every calculation you query route data, graph is built based on it, and graph calculation is done. To reduce data in query you can use BBOX
b) in Spatialite Djikstra you pre-generate graph for a table, so you have it as binary fields in special table. This is done once. From about 300MB of routes I got 20MB of graph data. For query this graph is loaded to RAM for calculations, and if you dont have enough of it then it crashes. Actually graph generation itself is quite fast, maybe it could be done for every query, then BBOX system could be hacked in reduce graph size. 

Anyway still bbox limit trick does not scale, especially for longer diagonal roads like "from Seatlle to Florida".

My question was what is approach of NiuRouting to pregenerate and keep graph data?

Jaak