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

Chris Browet cbro at semperpax.com
Sun Nov 9 16:55:48 GMT 2008


2008/11/9 Stefan de Konink <stefan at konink.de>

> Chris Browet wrote:
>
>> For Merkaartor, I also implemented a Binary file format (see
>> http://wiki.openstreetmap.org/index.php/Osb_spec_v2)
>>
>
> I read it and has some valid points :) UTF16 handling is not yet my thing.
> I presume I could also implement this in my Planet extractor. Or do you
> already have a simple generator for this?


UTF16 is just the default for Qt strings ;-) wchar* is UTF16, too. There
definitely are UTF characters used, so char* is probably too restrictive,
unless you handle UTF yourself.

>
>
>  There is nowadays no provision fur updates/diff, although the region-based
>> paradigm allows specific updates.
>>
>
> Jup; I see where you come from, and I guess this always requires
> compromises:
>
> - Empty space in the document (easy for compression)
> - Allow 'stackable' documents if this is all implemented per tile, it
> shouldn't be any problem; just ask the server to give all diffs from time X
> to Now.


ATM, my region size is ~1 km², which creates files, strings included, of
500kb to 1Mb. Decision is to be made whether it is useful to handle diffs
rather than downloading the full region.
Obviously, if the goal is to have a full up-to-date planet, this is not
viable. It is manageable this way up to the state/province level, I think.

>
> - Use separate files for strings and indices.


Problem with this is that you will have one huge string file (if that's what
you mean), which will have to be loaded in memory

>
>
> I would like the combination of solution 2 and 3 the most.
>
>
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081109/38b7bf7d/attachment.html>


More information about the dev mailing list