On Thu, Dec 10, 2009 at 12:19:59AM +0000, Neil Jerram wrote:
> 2009/12/10 Fox Mulder <quakem...@gmx.net>:
> > Neil Jerram wrote:
> >> 2009/12/9 arne anka <openm...@ginguppin.de>:
> >>> 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:


-- Sebastian

Attachment: signature.asc
Description: Digital signature

Openmoko community mailing list

Reply via email to