[Routing] monav preprocessing 32bits vs 64bits OS

[Quach Minh]

Hi Christian,

You indicated that the preprocessing of Europe needs 10GB RAM --> 64bits OS
is required.

Is it trivial to move from 32bits to  64bits OS? Is your data structure
designed to work on both platforms? Is it easy if I want to add some
features to the data?

Regards,
Minh


On Tue, Aug 24, 2010 at 10:30 AM, VeaaC FDIRCT <veaac.fdirct at gmail.com>wrote:

> 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
>
> _______________________________________________
> Routing mailing list
> Routing at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/routing
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/routing/attachments/20100826/cee1bcc9/attachment.html>