XAPI Beispiel arbeitet sehr unzuverlässig

Ich habe mir jetzt das “osm_xapi” Beispiel nachgebaut, aber es funktioniert äusserst unzuverlässig.

http://dev.openlayers.org/sandbox/fvanderbiest/openlayers/examples/osm_xapi.html
http://www.orpatec.ch/osm/tools/test.php?lat=48.9116&lon=5.5247&zoom=14&layers=M

Erst einmal hat es noch einen Programmierfehler, XAPI wird nach dem Start nicht sofort aufgerufen, sondern erst nachdem die Karte gezoomt oder verschoben wurde. Leider bin ich scheinbar nicht fähig, diesen Fehler zu finden und zu beheben.

Danach funktioniert das Beispiel (beide Versionen) einfach mal nicht, aber wenn ich den Firebug hervorhole geht es dann doch plötzlich. Zumindest sehe ich dann den GET-Aufruf. Dabei sehe ich Antwortzeiten im Sekundenbereich oder auch Server-Timeouts nach 30s. Komischerweise werden diese Timeout öfters mal als OK zurückgemeldet statt als Request-Fehler. Es kann sein, dass dies mit einem Request-Abruch zu tun hat, sicher bin ich jedoch nicht. Verschiebt man die Karte wärend einem Request, ergibt das einen Abbruch und neuen Request.

Und zu guter Letzt funktioniert die Ladeanzeige im SeaMonkey nicht richtig, die Gif-Animation läuft nicht. Komischerweise funktioniert es im Uralt-IE6!?!

Wyo

soweit ich weiss wird beim zugriff auf den xapi-server eine “rufumleitung” gemacht. da antworten verschiedene rechner. und diese sache ist sehr instabil.
sehen kann man das relativ einfach, wenn man mal mit wget den xapi-server anspricht.
das könnte der grund für dieses “komische” verhalten sein.
gruss
walter

Es gibt auch die Möglichkeit den Server direkt auszuwählen. Dazu waren im Wiki http://wiki.openstreetmap.org/wiki/DE:Xapi einige Server aufgeführt. Auf der englischen Seite sind auch noch farbliche Markierungen. Ob diese sich mit dem Betriebszustand ändern oder einfach der Hervorhebung dienen weiß ich nicht.

Aus der Antwort von Ian Dees (http://gis.638310.n2.nabble.com/XAPI-server-unusable-tt5796609.html) kann man schliessen, dass die XAPI-Server sehr stark belastet sind und darum der Allgemeinheit keine bessere Verfügbarkeit ermöglicht werden kann. Fragt sich nur, wer oder was da für diese Belastung der XAPI-Server verantwortlich ist.

Fazit: Für die Allgemeinheit ist XAPI unbrauchbar.

Wyo

ist doch irgendwie logisch: immer mehr leute -auch du- verwenden den xapi-server. und der geht dann halt irgendwann in die knie.
gerade die versuche, live-daten für irgendwelche online-karten herunterzuladen, sind schon etwas resourcen-lastig.

da war mein frühzeiter entschluß, einen anderen weg zu gehen, wohl nicht ganz so falsch.
gruss
walter

Welchen Weg und wie?

In einem anderen Thread hat er mitgeteilt, dass er statt einer XAPI abfrage eine lokale Datenbank auswertet, welche er mit OSM Daten gefüttert hat.

postgresql datenbank, postgis, osmosis 0.37ff simple schema mit hstore

zur not tut es auch postgresql mit osm2pgsql
http://wiki.openstreetmap.org/wiki/DE:HowtoMinutelyHstore,
wenn man nur einfache sachen machen (z.b pois)
oder rendern will.
ich will osm2pgsql nicht “niedermachen”. es ist dafür entwickelt worden, die daten zum erstellen von karten vorzubereiten.
dabei gehen aber viele sachen verschütt, die zum rendern nicht benötigt werden.

mit “meiner” lösung würde ich mich bestimmt schwertun einen renderer anzuschmeißen aber das hatte ich auch nicht vor.
es war ein langer weg aber jetzt bin ich ganz zufrieden.

p.s. osmosis ist ein JAVA-programm und osm2pgsql benutzt osmosis als rechensklaven.
daher kommt diese lösung für dich ja nicht in frage.

http://forum.openstreetmap.org/viewtopic.php?pid=105591#p105591

gruss
walter

Ich versteh diese technischen Feinheiten nicht.
Aber gibt es keine Möglichkeit, einen besseren Server für XAPI anzuschaffen? Spendenaktion?

sicherlich ist das machbar (geld, platz, administration, …)
ich bin aber der ansicht, dass die XAPI, die ja nur ein read-only Ableger der API ist, nicht für solche Sachen geeignet ist.
Die Api wurde afaik dafür entwickelt, das Herunter- und Hochladen von OSM-Daten für die Datenpflege (Editing) zu ermöglichen.
Erst später kamen dann andere Anwendungen dazu. Und jetzt wird es halt eng.
gruss
walter

Mir ist noch eine weitere Möglichkeit eingefallen, die (X)-Api nicht zu benutzen/belasten:

download von osm-files (aka planet-files) und change-files.
verarbeitung der osm-rohdaten mit garries perl-scripten.