On Thu, Dec 10, 2009 at 12:19:59AM +0000, Neil Jerram wrote: > 2009/12/10 Fox Mulder <[email protected]>: > > Neil Jerram wrote: > >> 2009/12/9 arne anka <[email protected]>: > >>> not to belittle the effort -- but in what respect will it be different > >>> from navit? > >>> would it be worth a consideration to use navit's engine, maybe improving > >>> it and add a new efl based interface? > >> > >> Good question. > >> > >> For me the frustrating thing about navit is that it doesn't share maps > >> with tangogps. So: > >> > >> - if you do consider helping navit instead, please consider enhancing > >> it to use the same maps as tangogps > >> > >> - if you continue with your own project, please consider making it use > >> the same maps as tangogps. > > > > I don't think that this would be a good choice at all. > > Tangogps uses png pictures with no routing information within these > > files. For a navigation application you need vector images to determine > > the path for routing. And the data for maybe a whole country in png and > > for all zoom levels would be a few gigabyte with tens of thousands of > > files. Compared to the vector format navit uses which is only a few > > hundred megabytes in one file. And it could be rendered in all zoom > > levels because it is in vector format. > > So if something should be changed, than it should be tangogps and > > allother apps that uses png files to use a vector format like navit does > > which is way better for this purpose. > > Thanks for following up and explaining this; what you say makes sense. > I suppose I was representing the non-technical point of view: "I've > already downloaded a pile of map data once, why should I need to > install or download it again?" I can see now why navit can't use only > tangogps's bitmap data. > > But I would guess that a combination could work well: bitmap data for > display, plus vector data for routing. The bitmap data could be > shared. It would take a lot of space per tile, but would only be > needed for places visited and zoom levels used. The vector data would > be needed over a much larger area, but would take much less space per > square kilometer. > > I guess the problem then would be ensuring consistency between the > vector and bitmap data...
You may be interested in this Google Summer of Code project: http://foregroundnoise.wordpress.com/2009/08/19/gsoc-09-final-report/ -- Sebastian
signature.asc
Description: Digital signature
_______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
