Fox Mulder Quakeman1 at
Thu Dec 10 10:47:53 CET 2009

Neil Jerram wrote:
> 2009/12/10 Fox Mulder <Quakeman1 at>:
>> Neil Jerram wrote:
>>> 2009/12/9 arne anka <openmoko at>:
>>>> 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...

If you already have the vector data you doesn't need the bitmap data
anymore because you can render the displayed map directly from these
data. That is what navit already does and therefor a combination of
vector and bitmap data makes no sense. It would make the data redundant
and more complicated.


More information about the community mailing list