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 <[email protected]>wrote: > On Tue, Aug 24, 2010 at 9:31 AM, feverzsj <[email protected]> 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 > [email protected] > http://lists.openstreetmap.org/listinfo/routing >
_______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
