[OSM-dev] OSM data on on-board-terminals

[Udo Giacomozzi]

Hello OJ,

Saturday, March 7, 2009, 3:10:19 PM, you wrote:
OW> we did a bit of work with python/cairo that sounds similar to your idea:
OW> http://wiki.openstreetmap.org/wiki/Pyrender
OW> the way that works is: you have lots of OSM files each containing
OW> enough data to draw one tile.  Many formats have been tried- osm.gz
OW> files are probably easiest to understand.

osm.gz would be a compressed XML file, right?

I'll have a closer look at Pyrender..


OW> then have a program which renders those to PNG.  Pyrender does this
OW> using cairo, but any graphics library will do.

I'd like to avoid the PNG step as Gnash/Flash is a fully vector-based
and avoiding any raster graphics would drastically improve quality
(and performance, probably). The real rendering is usually done by AGG
but Gnash supports OpenGL as well.

However, the way Pyrender stores the data is probably also suitable
for my idea.


OW> You can use it as a library ('give me PNG data for tile x'), or python
OW> can even run its own http server if you want to run your program as a
OW> javascript page or something in an embedded web browser.

In my case Gnash would run stand-alone and directly access the
graphics card frame buffer without any HTTP server around. But in
general my idea would work in any environment that can serve vector
map data (not PNG files), including a normal web site. In such a case
the binary map data (that's currently used for Symbian phones, AFAIK)
would work but I need something that can be stored in something simple
as a normal file or a lightweight database (SQlite for instance), at
least.


OW> As you say, the benefit of storing data instead of tiles is that you
OW> can update rendering rules on-the-fly, while still having the PNG
OW> tiles output for caching etc.

Correct, and you can rotate/scale the data on the fly without any
quality loss or generate some sort of 3D view (just as a classic
navigation computer).

Udo

-- 
Udo Giacomozzi