Navigation

Neil Jerram 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
square kilometer.

I guess the problem then would be ensuring consistency between the
vector and bitmap data...

Regards,
        Neil



More information about the community mailing list