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
Hi
On Thu, 23 Feb 2012 11:26:49 +0200
Jaak Laineste <jaak@nutiteq.com> wrote:
What is the project you're talking about here?
That is my "own" home-grown current project
of creating a car-navigation tool based on
-OSM
-mapnik for map generation
-SQLite + spataialite for some geom data
-trsp algorithm from pgrouting
So my comment about the time needed to build
the graph is for trsp.
I have not done memory cosumption measurments
how much memory a trsp graph needs. In my "environment"
memory is not really a "hard limit". Time is more important.
Regards
max
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_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
Hi again
Of course a "simple" bbox is also not always
helping much for really long routes especially
if lat/lon differs by a large amount since the
resulting bbox still may contain to much data.
If your memory limitation is really that
hard you can only try to "split" the route into
"managable" pieces by e.g. creating "connection points"
(waypoints) on e.g. country boarders or from city to city.
Of course the "hard part" is to find such points
A DB based solution is not really build for that kind
of "solution"
Regards
max
On Thu, 23 Feb 2012 11:12:50 +0100
Max Weninger <max.weninger@gmail.com> wrote:
Hi
On Thu, 23 Feb 2012 11:26:49 +0200
Jaak Laineste <jaak@nutiteq.com> wrote:
>
> What is the project you're talking about here?
That is my "own" home-grown current project
of creating a car-navigation tool based on
-OSM
-mapnik for map generation
-SQLite + spataialite for some geom data
-trsp algorithm from pgrouting
So my comment about the time needed to build
the graph is for trsp.
I have not done memory cosumption measurments
how much memory a trsp graph needs. In my "environment"
memory is not really a "hard limit". Time is more important.
Regards
max
> 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_______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users