[Routing] Binary file format

[Robert (Jamie) Munro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Boardman wrote:
>> Adam's WhereAmI software for Series 60 phones that uses his binary
>> protocol does quite a good job, but in general everything disappears one
>> zoom level earlier than you want it to.
> 
> It also supports UIQ3 and Series 80/90... the latest version (0.07) has 
> names dissapearing even more quickly... london etc looked way too 
> clutered, once I've moved over to using relations so that connected ways 
> with the same name have the same place where its stored I'll probably 
> start drawing names at higher zooms again, also I should implement some 
> name prioritisation and collision detection... in terms of other 
> features feel free to suggest new max zooms for visibility.

Actually, looking again on my mobile, it seems better than I remembered it.

>> Why not project into mercator before splitting into tiles, like the
>> slippy map does, then it will be the same distance in both directions.
> 
> I've avoided mercator as it distorts things too much at the top/bottom 
> of the map, I've gone for at the center of the current view make one
> pixel equal one meter (at max zoom). Pre v0.06 I think I had lat/lon 
> reversed so things were double distorted!, but its fixed now, so circles 
> are circles. Granted its a floating point multiple for x/y locations of
> everything every map draw, but I've never found the slowness of that to 
> be at issue, symbian db vvv slow, text drawing vv slow, but a few 
> multiplys it dosnt seem to have problems with.

Yes, but this means that at high latitudes you are going to be looking
at a very narrow band of a lot of very short fat tiles, where if you
stored the tiles as mercator, you would have tiles that were roughly
square at all latitudes, and compatibility with slippy maps. I'm really
talking about the binary protocol here, not the application. The
application can still reproject them into a local meter grid, or even
some kind of 3d projection, if that's what it wants to do.

>> Also, I'd work in binary fractions rather than degrees.
> 
> Also I dont bother with binary fractions, just div/mul 1000000, gives 
> you ~11cm rather than 9cm, which is still way more accurate than we 
> need... Store everything in signed 32bit ints etc.

Err, 9mm, not 9cm. (40 075 016.686 m) / (2^32) = 9.33069193 mm) :-) And
you also get the right thing happening at the date line and at 0.
Another way to look at it is to just div/mul 2^32/360 =
11930464.7111111. You can probably just replace the constant in your
code. I don't see what advantage using 1000000 gives you other than it's
a bit easier to remember and type in (although I'd probably get confused
between 100000, 1000000 and 10000000) :-)

Robert (Jamie) Munro

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHXqS8z+aYVHdncI0RAmiyAKDK6tNOlyZcDrFZMJu9OdZISy2tywCeL0If
HeSHkeXF42+TAW8BWac7hg4=
=+t2+
-----END PGP SIGNATURE-----