[Routing] monav, RAM and disk usage

[VeaaC FDIRCT]

On Tue, Aug 24, 2010 at 9:31 AM, feverzsj <feverzsj at hotmail.com> wrote:
> hi, list:
> The ram usage of preprocessing seems really huge. Does it have some slim
> mode(like Osm2pgsql).

Not yet, but it is on my list of features I want to implement. I will
most likely use the STXXL library, thus also supporting parallel discs
to swap data to.

> The client ram usage is fairly small. The graph disk usage is also all
> right. But the renderer data is too huge to fitting in most mobile device.

The render data uses a large amounts of memory at the moment. It is
not impossible to use it for country-sized graphs, though. E.g., my
mobile phone comes with 16GB storage space, Germany needs about 4-5GB.

For the time being you could save memory by using less complex
style-sheets for Mapnik. This should allow the PNG compression to
reduce the file size. If you are desperate to shave of a few more
bytes, try downloading PNGcrush and activating the option in the
MapnikRenderer to use it one the tiles. This will easily quadruple
your preprocessing time, though.

> Currently, monav seems not to generate any preprocessed vector data for
> rendering. And the render plugin is directly based on the original data.
> As a whole mobile nav solution(from the glance of the thesis), will monav
> have some binary vector map format and render plugin that is able to render
> vector data?

It is planned for future versions. I have only little experience with
fast vector graphics, however. Therefore, it may take some time until
I actually implement it. Right now I am working on ( the order is not
necessarily fixed ):
1. turn restriction / penalties ( requires work to integrate it
correctly with the routing algorithm )
2. house numbers
3. parallelization
4. "slime mode"
5. vector renderer

Of course I would also be glad if someone else wanted to develop /
port a vector rendering plugin.

> For example, gosmore packs all the data in one binary file, and the
> preprocessing is really fast and uses less ram and disk.

The problem is, that some algorithms MoNav employs require extensive
preprocessing, e.g., the routing plugin has to compute about 50+
routes per node and insert about one shortcut edge per original edge
into the graph. Although this allows the client application to have a
very low memory footprint while still being extremely fast, it also
has the drawback that the preprocessing takes up much time and
resources. While I plan to implement the "slim mode", it will require
a lot of work to avoid having to load the whole routing graph into
memory at once.

Greetings

Christian Vetter