[Routing] Wiki-Page for defining OSM binary file format created

[Nic Roets]

> Interactive rendering is a big point in rotuers and differnt
> from tile-rendering or rendering in editors that people on the
> dev-list would know more about, wouldn't they?

Well

>> Development is not all about design and programming. A lot of
>> investigation, analysis, testing and documentation is required :
>> * The ARM CPU has a builtin MMU and there's no point in duplicating
>> that. Mobile developers should really look into mmap() for their
>> programming language and operating system. It will be a major step
>> towards a mobile data format.
>
> Thanks for the suggestion. However this makes the assumption that
> a language that can do mmap is used (I used to write embedded java.)

Many C programmers does not know about mmap() but it still exists.

> and limits input-checking (how to test a pointer for validity?).
> However on the pro-side it can make walking the graph very efficient.

An array will get it's limit from the piece of memory that was
mmapped. AFAIK, Java limit checking is done in software, which allows
interesting things. Bruce Watson told me they would ask Java for a
smaller limit. Then they could write a while loop with TRUE as it's
condition and the exception handler will terminate the loop. Very
efficient.

> Does mmapping data-structures with links work when the file comes
> from another device where memory-locations may be different?

The file contains indexes. Converting it to pointers does not take
many CPU cycles.

>> * Windows (incl WinCE) comes with fast rendering of rotated text. Can
>> other mobile platforms do it fast enough ? I find cairo a bit sluggish
>> on my notebook, perhaps it's really bad on OpenMoko...
>
> I don't think this affects the data-format at all.

If we know what software we're going to support, we will have a better
idea what hardware we're going to support. Then we will know what the
space and performance issues are going to be.

> Yes, mobile editing is usefull. Do you suggest to not limit the format?

No. Mobile editors should duplicated any nodes used. Those nodes
should be merged with the existing / real node to during
postprocessing when appropriate. Same goes for ways.

> Do you have further arguments supporting the point I think you wanted to
> make?

There are so many :
1. Agreeing on APIs (function prototypes) are better than agreeing on
data structures.
2. Simplify, simplify, simplify.