In message <[EMAIL PROTECTED]>
"Martijn van Oosterhout" <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 27, 2008 at 1:34 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> > > > x = (int) Math.floor((longitude + 180) * 65536 / 360);
> > > > y = (int) Math.floor((latitude + 90) * 65536 / 180);
>
> > Yep - the input (after adjusting to zero) is between 0 and 360 (for
> > the longitude) or 0 and 180 (for the latitude) and we want to produce
> > a 16 bit integer so the result needs be between 0 and 65535 or we will
> > overflow sometimes.
>
> Interesting. so the area covered by the quadtiles at the edge of the
> map is half that of the rest of the tiles. Was this scheme chosen
> specifically or is it just the way it was done at the time.
>
> If s = 360/65535 then:
> quadtile 0,0 is [0,0.5s]left/right and [0,1s] up/down
> quadtile 1,1 is [0.5s,1.5s]left/right and [1s,3s] up/down
Umm... It was done that way because it produces the range of numbers
that I wanted? What's the alternative? The only one I can see would
require you to use a round towards zero operation to cope with the
negatives and that's not something that is easily available in most
languages.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
