[Routing] monav, RAM and disk usage

[Tim Teulings]

Hello!

> The patch can be done easily, but the behavior may differ. Msvc only
> supports a small subset of c99 features and posix stuff. I'll suggest
> you use c90 headers for compatibility, and use boost lib for other poisx
> headers and functions. For example, msvc doesn't have <stdint.h> and
> some cmath function like round, lround, instead, one can use

OK. It would be nice if you can send me a list of "things to avoid" or  
a diff of your changes, so I can change the code. Depending of the  
size of the changes I see possible alternatives:
* Use ifdefs (only if the amount of changes is small)
* Move such includes to a project header that does all the includes  
(again possibly with ifdefs)
* Move to supported includes.

A suggestion would be helpful.

> <boost/cstdin.hpp> and <boost/math/special_functions/round.hpp>.
> Of course, I'll be glad to make libosmsocut more portable and "native"
> under windows.

I would like to avoid the use of boost if possible. I tried to switch  
to boost for another project a longer time ago and even didn't get it  
to install under Windows because of some
strange (phyton based?) build tool at that time. I think installation  
is now easier but still would like to keep the installation barrier  
and external dependencies as small as possible. Curremntly the only  
forced dependency is libxml and this could possibly be droped for Qt  
users (AFAIK Qt has also XMl parsing support) if changes are small. So  
boost for me is only an option if there are substancial benefits and  
very easy installation and high portability.

> Pls download http://www.webfilehost.com/?mode=viewupload&id=4179785,  
> it's a small area of shanghai, downloaded by
> josm several weeks ago.

Thanks. Download worked and I got some problems because of corner  
cases because of the small size of the file (no relevant  
relations...). I did some changes to the code so it should not be more  
robust. TravelJinni and OSMScout now corretcly show the data. Note  
however the file I downlaoded shows Prag not Shanghai ;-)

Some comments regarding TravelJinni and OSMScout:
* The initial shown area is currently hardcoded  
(TravelJinni/src/View.cpp and OSMScout/src/MapWidget.cpp). You  
currently have to change this to get the relevant area shown on  
startup. The bounding box data is there, I just have to addapt the  
code to read it on startup. The plan is to work on map installation,  
selection and application setup after I finished work on coastline  
drawing.
* The current implementation of the name indexer expect at least one  
valid administrative area arounf the data. This is simple to fix for  
the indexer (just store the root node of the tree, too) but is more a  
possible useability problem (How do you search for a street in a city,  
if there is no city in the index? Add a blank city name?).

>> That I do not understand. Which of the offered applications did you  
>> use to render a map?
>
>> From http://framstag.wordpress.com/2010/08/03/libosmscout-now-supports-qt/:
> "I also added OSMScout, a simple Qt application that mimics parts of
> TravelJinni (the libillumination/cairo counterpart). It not yet has all
> the features TravelJinni has, but already shows how map integration
> should be done in Qt."

Should work now. Have seen the map on screen. See notes above :-)

>> Yes, more intelligent label placing is on the TODO list. I have  
>> some ideas, but did not yet have the time to work on it.

> You may take a look at mapnik, label_placement.hpp,
> markers_placement.hpp, placement_finder.hpp.
> Actually, I think mapnik is a good choice for rendering custom vector
> data for desktop computer. You just need to write a datasouce plugin,
> add your file and style in the map xml, and you get every cool thing
> that mapnik offers (awesome rendering, general style solution, python
> bindings, and should be fast enough for desktop computer).

Because of the modular structure of libosmscout (map drawing and  
database handling are seperated) it should be possible (in theory) to  
put mapnik on top of the database code of libosmscout. Since  
libosmscout is designed to work fast on slow system with limited  
memory it may be still valid to prefer osmscout map drawing ;-)

>> Definitely. I was surprised how slow Qt was in rendering compared  
>> to cairo. I would like to try to use a OpenGL accelerated version  
>> of QPainter to see if this works better.
>>
> I'll consider using agg. It's small, portable and fast under most platform.

I did a quick scan: It looks very low level and the API is a little  
bit unintuitive to me (and cairo and Qt personally cover all my target  
platforms), but since the general requirements for a backend are:

* vectorial polygon line drawing (any width, any color, alpha channel)
* Influence line ending style
* vectorial polygon area fill (any color, alpha channel)
* Font handling (font loading, font styles, size of text bounding area)
* Drawing text, especially along any path (any color, alpha channel)

this library could be used as possible backend, too. I assume if you  
are experienced in agg, it might take you < 1 day for first results,  
possibly 2-3 days to finish work. The drawing backend interface  
currently is suboptimal because it contains some logic that should be  
placed into the base class backend driver, adding further backend  
should help refining the interface to fit better. After refining,  
implementation is done likely even faster :-)

> It's all right for desktop application. However, mobile devices usually
> have very limited system resource. For example, win mobile commonly
> limits its file handle within 40, and you are still in a multi-thread

My personal target platforms are maemo/meego (and of course iOS ;-)),  
which does not have such problems (unix based). Note that currently  
not all files generated are necessary on the traget platform (raw*.dat  
are generated internally for faster processing). Nevertheless I still  
count around 14 files for read access (including my current routing  
implementation). It should be possible to merge some of the files  
without rewriting too much of the code, but as told before I might one  
might get into 2GB/4GB file size limits in that case (possibly with  
moving indexes in one and data in a second file this could possibly be  
avoided). Have you any experiences in this?

> environment. WM is generous, while for some lightweight mobile system,
> it will be a disaster. For example, a uc/os based mobile system I worked
> on several years ago limited the file handle within 6 for the whole system.

Ohh :-/ Don't call that OS ;-)

>> Btw., I'm currently working on getting coastline and oceans correctly drawn.

> So, any problem?

No, just to state that I'm still working on it :-)

-- 
Gruß...
    Tim