----- Original Message ---- > From: VeaaC FDIRCT <[email protected]> > On Thu, Aug 5, 2010 at 2:09 PM, flo <[email protected]> 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 _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
