[OSM-newbies] Should QuadTiles use base 5 data instead of base 4?
Kelly Jones
kelly.terry.jones at gmail.com
Mon Dec 24 01:53:03 GMT 2007
One thing I don't understand about QuadTiles is the use of base 4
data. For example, if A=NW, B=NE, C=SW, D=SE (just like at
http://wiki.openstreetmap.org/index.php/QuadTiles), then "ACB"
represents a large chunk of the western USA.
This makes sense.
However, if convert 00=A 01=C 10=B 11=D, we get:
000110 (base 2)
This doesn't make sense, because that's really the same number as:
00000000000[...]000110 (base 2)
In other words, we're using "00" to mean "NW corner", but forgetting
that "01" and "0001" are equal as numbers (they're different as
strings, but equal as numbers).
Should we store an extra bit to record the granularity/size of the QuadTile?
My thought: use base 5, with 1=NW corner, 2=NE corner, 3=SW corner,
4=SE corner.
So, "ACB" would become 132 (base 5) [42 in decimal]. Of course,
"1320", "13200", etc (in base 5) would all be alternate reprsentations
of this tile (we now have multiple representations of a tile, but
that's better than ambigious representation).
To get tile inclusion we'd divide by 5 and throw out the remainder.
Vaguely related thought: do QuadTiles have to be "square"? How about
using base 9 with: 1=NW corner, 2=north half, 3=NE corner, 4=west
half, 5=east half, 6=SW corner, 7=south half, 8=SE corner (and 0 used
as above).
This would lead to tighter (rectangular-shaped) bounding boxes, and
we'd still have the "divide by 9 to get inclusion" property.
Note: We could get rid of all ambiguity by writing QuadTiles as
decimals (eg, ".132" and ".132000000" are the same number), which
might be worth considering (for storage, we could multiply the
decimals by 2**32 or 2**64 or something)
--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
More information about the newbies
mailing list