On Sat, 11 Oct 2008, Florian Lohoff wrote:
klingt einleuchtend, nur habe ich schon so listen mit zig einträgen
abgearbeitet und noch nie ist das "problem" aufgetreten. also rein
statistisch erscheint mir die erklärung nicht ganz einleuchtend.
aber ich werde mal den zu ziehenden bereich bei den neuen reports
vergrößern, das kann ja nicht schaden.
Also - das "problem" ist die API. Die funktioniert im prinzip so das
erst alle punkte in deiner Bounding Box gesucht werden. Dann werden zu
diesen Punkten alle wege gesucht und dann zu all diesen wegen alle
punkte AUSSERHALB der bounding box.
Dann kriegst du alle punkte und danach alle wege. Dann bekommst du noch
im map call alle relations die als member einen der nodes oder ways hat
die im obigen bei raus kommen.
D.h. wenn dein Way keinen node innerhalb deiner bbox hat bekommst du den
im map call nicht d.h. in JOSM siehst du ihn nicht. Bounding box
groesser machen und irgendwann taucht der auf - sobald halt _ein_ punkt
in deiner bbox liegt.
Das ganze ist nicht trivial zu loesen.
Es gaebe die moeglichkeit fuer ways in der datenbank pseudo
bounding-boxes zu erzeugen und bei ueberlappung mit der requesteten bbox
diesen zurueckzuliefern. Alternativ bei verwendung von postgresql auch
mit einem linestring und einem gis index.
Das Problem tritt bei tilesAtHome auch auf. Dort werden z.B. in Asien sehr
lange Wege nur teilweise gerendert, weil in den dazwischenliegenden
Abschnitten der API-Aufruf die kreuzenden Wege nicht enthält.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
