Navigation

On Thu, Dec 10, 2009 at 12:19:59AM +0000, Neil Jerram wrote:
> 2009/12/10 Fox Mulder <Quakeman1 at gmx.net>:
> > Neil Jerram wrote:
> >> 2009/12/9 arne anka <openmoko at 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:
http://foregroundnoise.wordpress.com/2009/08/19/gsoc-09-final-report/
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.openmoko.org/pipermail/community/attachments/20091210/78af1524/attachment.pgp