[Routing] monav

[flo]

----- Original Message ----
> From: VeaaC FDIRCT <veaac.fdirct at gmail.com>
> On Thu, Aug 5, 2010 at 2:09 PM, flo <orangeman at teleportr.org> wrote:
> > Are there monav / routed specific mailing lists?
>
> Not yet, but we will setup a mailinglist if there is popular demand for it.
>
> > for compiling mapnik has to be present.
> > does this mean a full installation including postgis setup?
> > Isn't there an internal kd tree in use?
>
> If you want to generate files for the MapnikRenderer plugin you have
> to setup a functional postgis database. Nevertheless, if you just want
> to use the OSMRenderer plugin, which fetches tiles from the
> OpenStreetMap server, or use provided data packages no database is
> needed.
I installed the following aptitude packages: python-cairo libmapnik0.7
mapnik-utils python-mapnik
and removed mapnikrenderer from plugins/preprocessor_plugins.pro
but still get "cannot find -lmapnik" Is mapnik not installed correctly?
how can I build just the contraction hierarchies part?

>
> > Is there any interest in porting to android?
> > How far go the Qt dependencies beside the Ui (and maybe qdebug)?
> > Can you imagine compiling it with the android native development kit?
> > Combining monav and mapsforge seems like a perfect match to me :-)
>
> MoNav uses Qt for:
> - GUI
> - file access / memory mapped files
> - accessing GPS hardware
> - timers
> - strings / UTF-8 encoding / decoding
> - debug output
> While porting the plugins to a different toolkit is not be much work
> due to sparse Qt usage, the GUI would have to be rewritten completely.
> I have heard that Qt might work on Android, though, and would advise
> to pursue that.
Someone once showed me a Qt apps running on his android. It was really
snappy and responsive! but requires some additional installation
hassle (for now)
Nevertheless it could be useful to provide monav functionality to the
dalvik world. One of the "nice"
things in the android runtime is this "inter-app-mashability" of
different (lously coupled, late runtime bound) "components" via so
called "intents" and "tasks". (everything worth performance is
implemented with the native c++ ndk. the dalvik/java environment is
just to dynamically glue these parts together..). Monav could provide
general on-device routing (deluxe++) for other apps to make use of.
For example http://code.google.com/p/osmand would really benefit to
have monav as an additional routing service or
http://code.google.com/p/mapsforge does beautiful vector rendering..
also that clever gps-road-snapping would make sense as native
functionality.. plz ping me if you are interested.

>
> > How big does such a address lookup file (trie / tournament tree) become?
> > I can't believe that number 0.7kb for whole germany. What did I get wrong?
>
> The main trie file containing all place name should be around 3MB, the
> sub-trie file containing all the street name tries about 37MB and the
> way data file about 70MB. While the main trie file should always be
> the same size, the sub-trie file depends on the type of streets you
> are routing on. Only routeable streets are imported into the address
> lookup.
> If your files are a lot smaller than the data packages offered the
> importing seems to be at fault. Have you setup a correct speed profile
> or used the default one? Have you selected an appropriate vehicle
> type? Is your osm file compressed as bz2 or uncompressed?
I was refering to your thesis page 41: "the average street name trie
is quite small, e.g., about
0.7KB for Germany."

flo