First of all, forgive for my bad English, I hope to make myself understood well.
I’m trying to develop for Android a free offline OSM Data viewer to render on the fly the information (live rendering). First I have been reading documentation on the binary file formats (PBF format, OSMBin, Osm Binary, Binary Osm for Mobile), because I only need to read and not to write. I watched too a google protobuf library.
My idea basically is open the application and download from http://download.geofabrik.de/osm/ the osm.pbf file, save it to SD and interpret the flight.
There are programs that do something similar (Osmand, Navit, Mapsforge) but create their own binaries (OBF, bin, map) and do not understand why these conversions. Perhaps it is not technically possible to do what I have in mind? It may take too many resources to the device to interpret and display that file? What is the reason? Could be done?
I’m still a little lost, take pleasure in someone to help me and clarify my ideas. Also any code for your study will be welcome.
But it won’t be easy, and resource heavy. On one level what you’re making is on the fly rendering, like the OSM tile server using mapnik with postgres and a webserver.
On the other hand, maybe it is more like qlandkartegt (that’s opensource btw), which renders maps from map images, created with mkgmap from OSM data. If you could get that to work a lot of people would also be happy
Just think it is difficult to make it a challenge even more fun. But I think it is possible, the pbf format is a binary file and osmand do it, not with osm.pbf but yes with its own format: OBF. And rendering speed is very fast and agile
You see some technical problem? If I don’t misunderstood that file is accessed by protobuf and so you can read the internal structure of osm.pbf. How do you see?
The hardware of the today smartphones are not so far from the specifications of any dedicated GPS. How have solved this Tomtom, you know something? I doubt that TomTom system works with tiles, seems on the fly rendering, isn’t it?
Sure, you can read the pbf structure, and use that directly. It can also be filtered and cut so one could display a map of just what one wants. Especially if there is an external “stylesheet” or something to define how it will look on the screen. But the pbf files can be very big, maybe that’s why Osmand and others use their own binary format to make things faster.
Well, now with the ideas more clear I will prepare a program that accesses to an osm.pbf file by protobuf to get an idea of performance. I don’t know how long it will take me, I’m afraid of “wasting” time and then the results not go too fast than I hope
OBF file (for example: spain) from osmand has a 188MB and osm.pbf has 236MB, the difference of size between them is small … hopefully the performance is similar too…
Saúl,
I’m not sure if interpreting .pbf files on the fly is the right way to supply your renderer with data on demand. PBF files are organised blockwise, but the blocks are sorted by nod id by default, so you would have to unpack every block before you can use the data. Each block is compressed (zip format).
I think you should use a special binary format which allows you to get direct access to the data. Some of the binary formats have been optimized for this purpose: they store lon/lat instead of node id reference to every point within a way.
If you cannot find a suitable format or the format’s description is too bad, then develop your own; you can optimize it for your special needs…
In my opinion Marqqs is totally right.
Actually the osm.pbf includes every information which is in OSM. Inclunding all those information you’ll probably never need. And it is optimized for less file size and not for easy rendering accessibility.
There are a couple of things which one probaly is not needing (FIXME or note tags, less used tags, some relations, …) or which are not needed in osm-style (like not saving each node on its own but only those which are independent. ways could have all their coordinates themselves).
