Hallo,
Kolossos wrote:
Was besonders unschön erscheint, ist dass x und y scheinbar untrennbar
miteinander verkoppelt werden. Meinen Plan die Tiles in bestimmten
Längengradbereichen abzufragen werde ich damit wohl zu den Akten legen
müssen.
Ich verstehe nicht ganz, was Du meinst.
Letztlich geht es bei der ganzen Sache doch nur darum, dass nicht alle X
Milliarden Tiles auf Zoom 17 in einem Verzeichnis liegen. Also teilt man
auf. Nun gibt es natuerlich viele Methoden, einen Pfad fuer das Tile
x=12345 y=67890 zu bestimmen; man koennte z.B. sowas wie
zoomlevel/012/345/067/890.meta oder so machen - aber auch hier waeren X
und Y miteinander vermischt.
Im konkreten Fall hat man halt eine Methode gewaehlt, bei der die X- und
Y-Koordinate des oberen linken Tiles im Metatile in 20 Bits
hingeschrieben werden, also
x = aaaabbbbccccddddeeee (a sind die hoechst-, e die niedrigstwertigen bits)
y = ffffgggghhhhiiiijjjj
und dann werden jeweils 4 Bits von einem und 4 Bits vom anderen zu einem
Verzeichnis zusammengesetzt:
aaaaffff / bbbbgggg / cccchhhh / ddddiiii / eeeejjjj.png
Theoretisch koennen in jedem Verzeichnis die Zahlen 0-255 vorkommen,
aber in der letzten Verzeichnisebene sind die letzten drei Bits immer 0,
wenn man mit Metatiles arbeitet, d.h. wir haben "e000j000.png", d.h. es
gibt nur 0.png, 8.png, 128.png und 136.png.
In den vorderen Verzeichnissen gibt es auch eine Einschraenkung des
Wertebereichs, weil es ja nicht auf jedem Zoomlevel 20-bittige
Koordinaten gibt. Bei allen Zoomlevels unter 17 ist das erste
Verzeichnis immer 0. Bei allen unter 13 das zweite auch. Bei allen unter
9 das dritte, usw.
Also eigentlich kann man damit schon arbeiten.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
