[OSM-dev] Binary OSM; the first pass encoder

[Marcus Wolschon]

Hello Stefan,

cool to see some progress here.
If you decide on an index-format I can implement a DataSource for
Traveling Salesman for it (however any updates can only be appended).
Did you have a look at
http://wiki.openstreetmap.org/index.php/User:MarcusWolschon%5Cosmbin_draft
? I am trying something similar but with fixed length records and back-links
from node to way to allow updates to be applied to the file.
1.4GB-135MB is nice but you still don't want to download 135MB every day to
have an up-to-date netherlands-file (let alone to do this for the planet).

I was quite occupied with another open-source-project of mine and
switching jobs but now I should have the time to finish implementing
my own  proposal in code and test it's performance.

Marcus

2008/11/9 Stefan de Konink <stefan at konink.de>:
> Hi All,
>
>
> Because I am getting more and more disappointed with the current state
> of affairs with respect to the downloading of OSM content some people on
> the Dutch OSM IRC channel thought of an alternative way of distribution
> that could potentionally get binary diffs after any possible download in
> the past.

Can you give some more specifics on the binary-diffs?
Is there some code or a spec for a service to get them?

> In principle it is nothing more than:
> N [long id] [float lat] [float lon] [time_t timestamp]
> [uint length of userfield] [non terminated userfield]

How do you encode the nodes of a way and the ways,
nodes and relations of a relation?

> If interested taking a peak is possible at;
> http://repo.or.cz/w/handlerosm.git?a=tree;f=osmbinary;h=1701a9194285a56e7a91536def314fb8b2e95350;hb=96c7b81af692df89bc6c5eba999e9bb61c92323c

I see you used float for lat and lon. Did you think about using long integers?
We don't loose any precision since the osm-db already saves them this way
and they are much smaller and faster to compute with.


Marcus