Es gibt 3 Tile Cache Server in DE
https://hardware.openstreetmap.org/servers/kalessin.openstreetmap.org/
https://hardware.openstreetmap.org/servers/katie.openstreetmap.org/
https://hardware.openstreetmap.org/servers/konqi.openstreetmap.org/
Die Sache nervt. Auch mit Tiles von einem .de Server lahmt es iwann, oder wird sogar blockiert?
Das doofe daran ist, dass es nicht einmal der Download der Tiles ist, die, wenn eh im Browsercache, nicht neu gedownloadet werden müssen, sondern die Sever-Anfragen werden gedrosselt. Wieso, weshalb und überhaupt eine Serveranfrage gestartet wird, wenn sich die Tiles eh im Browsercache befinden, wäre herauszufinden. Es wird mindestens gecheckt, ob eine neuere Version der Tilesdatei vorhanden ist. Muss denn das auch schon gedrosselt werden? Reicht es nicht nur den Download zu drosseln?
Dazu müsste man mal ausdiskutieren, wie schnell Mapper ihre Änderungen in der Karte sehen wollen. Und wieviele.
Ich für meinen Teil käme mit einem Browsercache von einem Tag oder mehr klar, denke aber, dass 1-2 Stunden für alle hinnehmbar wären.
Das ist auch der Punkt, wo sich hier die Katze in den Schwanz beisst: Auf der einen Seite findet rerendering zunehmend seltener statt, auf der anderen muss ich trotzdem requests an den Server schicken.
Da wird schlicht Arbeit, Strom und Geld und Frust verbrannt für nix.
Solange der Online-Editor ID als Standard-Editor gedacht ist, sollten Änderungen auch zeitnah online zu sehen sein. Gerade für neue Maper ist es mit Sicherheit demotivierend, wenn sie ihre Änderungen nicht zeitnah seehen können. Das ging auch in den letzten Monaten immer ziemlich flott, nur die letzten Tage dauert es ewig, wie ich feststellen musste. Es wäre gut, wenn das nur vorübergehend so bleibt.
Es ging einmal ganz schön schnell - bei Humanitarian geht es auch noch sehr schnell. Ich wäre schon zufrieden, am nächsten Tag meine Änderungen kontrollieren zu können.
Noch vor ca. 2 Wochen konnte ich Änderungen per ID im Zoomlevel 17 bereits nach wenigen Minuten sehen…
Mittlerweile scheint’s ja wieder gut zu laufen. Änderungen sind nach einigen Minuten schon neu gerendert 
Also, Langzeitanalyse. Da wurde wohl eine Drosselung hardcoded, bei allen Tile-Servern, global. Mies. #DrosselOSM
Die Sache ist verdammt mies, weil, es wird unterschiedlich gerdrosselt. Auf Privat-IPs wird schneller, sehr schnell, verdammt schnell, extrem gedrosselt. Blos nie F5 drücken! Das ist der Knopf für die Drosselklappe! Da hat man nicht lange Spaß. Privat-IPs: wenn ich den Code lokal am Home-PC teste, oder eben nur da verwende. Viel weniger schnell wird gedrosselt bei Server-IPs. Super toll dieses #DrosselOSM. Bei der Telekom abgeschaut?
F5 drücken ist zumindest beim Erstellen meiner Projekte ein notwendiges Übel, zur Konrolle.
Google Maps, hat seine Richtlinien verschärft, drosselt zwat nicht, sondern verändert die Tiles (dunkler mit Hinweistext) jetzt schneller als vor der Änderung letztes Jahr. Man muss zur Nutzung eher und mehr zahlen. Möglich, dass dadurch mehr OSM nutzen. Doch so ist das keine akzeptable Lösung.
Bei OSMAnd kann ich mir Tiles-Pakete downloaden und verwende diese sozusagen wenn auch nicht “lokal” aber doch “offline”. Die sind dann nach einer Weile nicht mehr aktuell. Daran könnte geschraubt werden. Also was mir reichen würde wären solche Pakete, wie zB für einzelne Länder, Bundesländer von mir aus. Das Updaten der Tiles müsste dann intelligent geschehen, also dass nicht immer komplette Pakete gedownloadet werden müssen, sondern nur die erneuerten Tiles ausgetauscht werden, per Timestamp oder was weiß ich. Lasst euch was einfallen. Ich warte hier bis zu einer halben Stunde und dreh Däumchen bis endlich die Tiles kommen. Ich komme nicht vorwärts.
Hast Du einen Link dazu, wo Du das belegen kannst?
Also “eine Drosselung” hat es seit mittleren Ewigkeiten (sicher mehr als ein halbes Jahrzehnt). Es ist auch gut so, da wir “Normalverbraucher” ansonsten schon längstens von den Grossscrapern verdrängt worden wären. Aber als Normalverbraucher wird man davon nichts bemerken (man kann natürlich durch häufiges F5 drücken einen Scraper emulieren, dann muss man sich aber auch nicht wundern).
Was dieses/letztes Jahr leicht anders ist, vermutlich google bedingt, ist die grosse Verkehrszunahme auf den Tileservern, siehe https://twitter.com/OSM_Tech/status/1080925873765793793 Es hat jetzt noch mehr Server im CDN, dass muss sich aber sicher zuerst etwas einpendeln.
Das sollte sich recht einfach erschlagen lassen indem man die …png/dirty-Markierung wieder* einführt.
Man macht in iD eine Änderung und iD fordert einmalig “dirty-tiles” an.
- Ich finde keine Quelle dazu, dass das dirty-markieren von Kacheln kaputtgemacht wurde, habe das aber so im Kopf und andere im OSM-Umfeld behaupten das auch. Aus eigener Erfahrung weiss ich, dass es tatsächlich nicht mehr funktioniert (oder mglw. nach Regeln funktioniert, die mir, oder MapperXY entweder nichts nützen oder nicht ersichtlich sind)
Wer nicht weiss, wovon ich rede, sowas: https://a.tile.openstreetmap.org/14/5487/8271.png/dirty gibt ein Feedback, funktioniert aber erfahrungsgemäss nicht (mehr)
Das wäre imho die beste Lösung für alle:
- Aggressivstes Caching in alle Richtungen (gibt’s egtl. die Internetprovider-caches noch? Bin da etwas lang raus)
- dirty rendert die tiles neu
- die tiles kommen mit neuem Namen im Browser an (sonst würde das caching greifen)
Keine Ahnung, wie zielführend das ist, aber der aktuelle Zustand ist auch suboptimal.
Das Thema hat irgendwie zwei Stränge. Einmal die Sache mit den Aktualisierungen, dem Rendern von gemappten Änderungen, und einmal die Sache mit dem Laden der Tiles im Browser an sich. Beides hat nichts miteinander zu tun.
Also die Infos in meinem letzten Posting waren gewagt, haben nun aber auch keine neuen Infos hervorgebracht.
Das mit dem Unterschied zu Privat-IP und Server-IP ist Quatsch, da die Tiles nie vom Server, sondern immer vom User-PC angefordert werden, also der Privat-IP, JavaScript, kein PHP. Es scheint aber einen Unterschied zu geben, ob die Dateien (html, css, js) lokal oder auf einem Server gespeichert sind. Das wird gleich möglicherweise interessant. Denn es scheint einen Unterschied in den Browsern zu geben, wobei Firefox lahmer ist als Chrome. Also liegt es eventuell auch an deren Caching und Serveranfragen und am Ende gar nicht an OSM. Wenn ich wüßte woran es liegt, würde ich das nicht schreiben.
Zumindest betrifft es openstreetmap.org viel weniger bis gar nicht, dort werden die Tiles nach wie vor mehr oder minder schnell geladen, während in einem anderen Browserfenster, das vorher(!) geöffnet wurde, das Laden der Tiles eingeschlafen ist.
Zumindest gibt es noch die Möglichkeit diese zu deaktivieren, zB mittels .htaccess. Das wird OSM wohl nicht machen. Als Enduser kann man die nicht deaktivieren. Das sollte aber wohl kein Problem dieses Thema betreffend sein, weil dabei geprüft wird, ob es von dem Angeforderten eine neuere Version gibt, und nur wenn nein, dann aus dem Cache geliefert wird. Wie schon weiter vorne erwähnt hat die Sache nichts mit dem Traffic zu tun, sondern mit den Server-Anfragen an sich, und würde dies dann ebenso betreffen. Siehe F5 drücken (was leider manchmal unvermeidbar ist, um Änderungen am Script zu sehen).
Ich plädiere weiterhin für eine OSMAnd Möglichkeit für Desktops.
Edit: Info dazu: Weil ich weniger ein Mapper bin und mehr ein Nutzer von OSM, hauptsächlich per Openlayers. Wenn ich einen Layer erstelle, dann muss ich die Tiles sehen, ob der Layer am rechten Platz ist, und F5 drücken, und so weiter. Dazu bräuchte ich keine up-to-date online-Tiles, da würden lokale reichen.
Wenn auch nicht direkt wie Sand am Meer, so gibt es doch ein paar Desktoplösungen, wenn man tatsächlich das (aka offline Kartendaten auf seinen Desktop herunterladen) will.
Aktuelle Situation bei mir (Ladezeit eines zufälligen Ausschnitts):
- openstreetmap.org: 30 Sekunden
- openstreetmap.de: 1 Sekunde
Sekundengenau kann ich das nicht bestätigen, aber ja, es ist weiterhin so, dass die Tiles weiterhin langsamer laden als Anno dazumal (Server in London, jetzt Amsterdam).