[OSM-dev] [OSM-newbies] URL for mobile binary protocol

Milo van der Linden mlinden at zeelandnet.nl
Thu Mar 20 14:55:34 GMT 2008


Anton Patiev schreef:
> Hi!
>
> I think that will be improper to limit mobile devices only to a mobile
> phones or PDA's. 
I agree! All Object oriented programming uses a generic structure that 
is language independant. I am currently looking into the source of 
OSM-tracker and find it hard to distinguish the functional concept. That 
is why I am following this discussion since I am looking for a general 
and usable functional concept that can be adapted, whatever programming 
language or environment one might choose to use.
Your discussion touches a conceptual approach that I would like to adapt 
and even though I am on a completely different development environment, 
I would love to see that in general I can learn from your approach.

For instance, In OSMTracker, presentation- ,business- layer are mixed. 
Before I dive in to the code I would like to take a step back to the 
drawing board and design a functional and technical concept.

> There are new classes of devices, such as, for
> example, MID's (mobile internet devices -
> http://www.intel.com/products/mid/), or Car PC's. In comparision with
> mobile phones they have more computational power or storage capacity.
>   
Again, I totally agree. It is simply lack of funds that keeps me stuck 
on my T-mobile Vario (which I recieved for free with my mobile contract).
> However, in my opinion, there should be different methods of access to
> the map data - for the different requirements. To provide routing on
> mobile device you need either vector data or server that computes
> routing for you.
>   
And this is an excelent point to set up a general set of methods; when 
to use raster, when to use vector, when and how to combine.
As for the routing, I have experience from the past that realy fast 
routing implementations are mostly built upon binary file structures 
that follow a model of graph-trees/graphs (I am a bit confused about the 
english term for this)
I have worked with succesfull implementations of many to many routing 
algorithms where the mathematical file structure consisted of binary 
node and way files that where ordered during pre-processing when being 
converted from vector. In practice this meant that everytime the 
GIS/Vector road network changed, the binaries had to be regenerated, 
sometimes taking more then 20 minutes to built. But when the binaries 
where there, routing of many to many simulations always stayed under 30 
seconds on a desktop machine (Pentium 4) for 1 to 1 routing, it was 
always less then a second.
> Best regards,
> Anton Patiev
>
>
> On 3/20/08, Milo van der Linden <mlinden at zeelandnet.nl> wrote:
>   
>> I know that Rob (Rubke) wrote a tool that is called OSMtiledownloader.
>> http://wiki.openstreetmap.org/index.php/OSMtiledownloader
>> It allows you to download tiles to the desktop given a certain directory
>> structure. This directory can then be copied to a mobile device and used in
>> conjunction with OSMTracker
>> http://wiki.openstreetmap.org/index.php/Osmtracker
>>
>> This solves the issue of complex rendering, and give you a base set of
>> tiles. OSMtracker also has a live tile download function, but it is not the
>> fastest around yet.
>>
>> So I disagree that you would need a mini mapnik on your mobile. I think it
>> might be good to build a standard API to handle rendering tiles based upon a
>> certain directory structure and a download API for getting tiles into your
>> phone via GPRS. The both combined will probably require less processing
>> power then setting up a mapnik server on the phone.
>>
>> Martijn Pannevis schreef:
>> Robert (Jamie) Munro wrote:
>>     
>
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>>     
> Hash: SHA1
>
> Jason Dent wrote:
> | I have a
>   
>> mobile map application. I have found that directly accessing the
>>     
> | tile
>   
>> server works the best.
>>     
>
> The downloads are HUGE! Some people have to pay per
>   
>> kB for mobile
>>     
> downloads. Also, you can't rotate and reproject the tiles, or
>   
>> give a
>>     
> sat-nav type 3d view, without horribly distorting the text. If you
>   
>> want
>>     
> to highlight a road or a point, you have to download the map details
>   
>> anyway.
>>     
>
> | Trying to draw all the map details at runtime
> | on a PDA is a bit
>   
>> much. It can be done, but pre-cooked tile are much
>>     
> | better.
>
> It's not "a
>   
>> bit much". *All* commercial sat-navs do it. When you
>>     
> consider how much more
>   
>> CPU power a modern PDA has than a PC of 15 years
>>     
> ago, and think about the
>   
>> kind of thing those PCs did (Doom, for example)
>>     
> drawing a map is easy.
>
>   
>> I agree that technically redering tiles on the mobile probably would be
>>     
> the
>   
>> best solution, certainly in terms of data traffic.
>>     
> However, to get nice
>   
>> looking tiles, you'd have to implement something
>>     
> like mapnik, on your
>   
>> device. I know it already took us quite some work
>>     
> to implement a nice map
>   
>> with scrolling tiles in J2ME. I'm sure building
>>     
> that with vectors, which
>   
>> scale with zoomlevels, and look nice, would
>>     
> take months, if not years, of
>   
>> development time. Thats why we choose to
>>     
> use tiles.
> I do want to look into
>   
>> more efficient ways of getting tiles, or parts of
>>     
> them, to the mobile.
> Kind
>   
>> Regards,
>>     
> Martijn
>   
>> Pannevis.
>>     
>
> _______________________________________________
> dev
>   
>> mailing
>> list
>>     
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
>   
>> _______________________________________________
>> dev mailing list
>> dev at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>>
>>
>>     
>
>   





More information about the dev mailing list