neiljerram at googlemail.com
Thu Dec 10 01:19:59 CET 2009
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
I guess the problem then would be ensuring consistency between the
vector and bitmap data...
More information about the community