-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tristram Gräbener schrieb: > Hello, > > I have the feeling that having data specifically for routing > doesn't troubles you. However plain OSM data is not usable as you > don't have the traditional edge/arc representation (points are only > geographical points and there can be multiple intersections on a > single way). How do you people handle that? Did I miss some nice > tool or misunderstood how data is organized?
Hello. I'm not sure who this was directed at but I'm answering anyway. Noone says that you have to use a traditional representation. But what most people do is to import the OSM-data into their own data-formats but not everyone does. I only split and filter OSM-data and have no problem walking the graph as long as my getNodeByID() and getWaysForNode() are O(1)-functions. > When I first thought about having a binary format, I thought about > boost's serialization. Of course this only makes sense if you use > boost::graph (I don't want to launch an other debate on that topic > ;) ). The idea was to be able have immediately the graph structure > ready to use without having to build it (it costs some CPU time > even on a full size computer). Actually on most mobile devices data-storage is flash and accessed using the same memory-bus that ram is used on. Thus you don't "load" your graph at all but you access it directly on the storage. > This brings me to my real concern: do you really want to have the > same data structure for graphical rendering and routing? Space > isn't really a problem on portable device (1Gb of SD card costs > just a peanut), loading/rendering speed and ram use will be much > more problematic. That's why I think for two uses the data should > be duplicated to have an fast access depending on the needs. It does not have to be the same data-structure but both are part of the format as walking a large graph and getting a route gets you nowhere unless you can display that route including street-names and at least the most important geographic (ocean, wood) and administrative (city) objects. Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFInF23f1hPnk3Z0cQRAuoaAKCPLvTE9L0YseCZOL40NaYWvtm/jQCfZsIk j04Rs3cZrPcUzJogdHW7IDU= =Inx9 -----END PGP SIGNATURE----- _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
