[OSM-dev] Proposal: Database accelerator and dirty tile marker based on simple algorithm.

[Nick Hill]

Nigel Magnay wrote:
> I still don't understand why dividing the world into simple quadtiles 
> has any problems at all.

I am not suggesting it has problems in itself. I am suggesting an 
alternative scheme which provides all the benefits plus a shortcut.

The alternative system which I proposed also exactly correlates to the 
1E7 locational system and easily correlates to degrees.

> 
> With a simple QT, I can represent, in, say, 64-bit integer form, the 
> entire planet down to roughly a square centimetre, which is, to be 
> frank, a totally unneccessary degree of accuracy, so the bottom few bits 
> are somewhat irrelevant.

I agree. The only down-side to the 1E7 system is a slightly lower degree 
of accuracy (2mm) which, as you say, is irrelevant.

> 
> The top-level tiles at, say, 32-bits gives about 610sqm in size. The 
> edges are easily definable in floating point values for doing 'is this 
> value in this area' conversions.
> 
> Having pre-parsed the entire OSM dataset (~15 million nodes) with and 
> without appending a calculated quadtile address (the earlier function) 
> makes a difference of about 10 seconds. For the entire dataset. 
> Performance is a total non-issue here, particularly compared with the 
> gains to be had in the actual querying of the data (we could replace 
> many of the horrendous 'select from blah where ID in 
> (very_huge_list_of_numbers)).

I am agreeing that a quadtile approach is good. I am proposing a very 
small change to the quadtile scheme which you posited.

> 
> The only thing I can see is that, at higher zoom levels, the edges don't 
> 'line up' with degrees of longitude. But I can't help thinking "so 
> what"? I can't see what I'm loosing here. And if it's really that big a 
> deal, then why not scale the size of the tilemap to be bigger than the 
> size of the world? I.E - instead of having longitude values of +/- 180, 
> have +/-200, and just never have any data in the 180-200 range ? 

The 180-200 is in the context of what I said, an invalid range. I think 
we are basically agreeing but disagreeing on the words used to describe.

I am actually positing a range of 0-214.7483648 but only using 0-180. 
This provides easy degree conversion.