David Reyes Samblas Martinez
david at tuxbrain.com
Thu Dec 10 11:37:50 CET 2009
2009/12/10 Fox Mulder <Quakeman1 at gmx.net>:
> 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...
> 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.
I find very useful to have a mixture of vectorial and bitmap not to
load the same data but other data like sat pictures, geological
data, or historical ones etc etc.
David Reyes Samblas Martinez
Open ultraportable & embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
> Openmoko community mailing list
> community at lists.openmoko.org
More information about the community