Ich zitiere mich ungern selbst, aber falls es immer noch nicht 100% klar geworden ist (was ich aus der mehrfachen Wiederholung desselben Sachverhalts leider schließen muss):
Nächster Punkt:
Nein, da ist jemand, der die Situation technisch sauber beurteilen kann und dir sagt, dass es einfach Unsinn ist. Es hat keinerlei Auswirkung und ist obsolet. Wir sind nicht mehr in 2010, wo das vielleicht noch Mittel der Wahl war (kann mich noch dunkel daran erinnern).
Die Maßnahmen sind noch nicht abgeschlossen… Die Beschaffung der neuen Server war ja erst für das zweite Quartal 2021 anvisiert. Auch steht noch ein Umzug von Rechenzentren nach Dublin an, und ich glaube in Schweden wird bald auch ein neuer Tileserver an den Start gehen. Da ist sehr viel Bewegung drin und wirklich kein Grund, hier die Flinte ins Korn zu werfen.
@Tirkon: Du mist glaube ich der Karte von osm.org zu viel Bedeutung zu.
Wir füttern primär eine Geodatenbank (Die Daten können ja jederzeit wieder heruntergeladen werden).
Ein Renderer ist und bleibt immer eine Möglichkeit die Daten darzustellen.
Und osm-Carto ist nicht die heilige Kuh und nicht zwingend die Meßlatte.
Denk dir die Karte von osm.org einfach weg. Ist das Projekt dann ein schlechtes? Oder ein gescheitertes?
Abgesehen davon wäre ein stures kartieren für/nach osm.org-Carto ein mappen für den Renderer…
Tirkon hat es zwar sehr überspitzt formuliert, aber wenn ich an meine Anfänge zurückdenke: ja, die Hauptkarte ist für Anfänger (die noch keinen Überblick über die vielen alternativen Renderer haben) elementar wichtig für das eigene Erfolgserlebnis und damit das Interesse, weiterzumachen.
Wenn man sich beim Eingehen auf neu hinzugekommene Postings wiederholen muss, ist das Antworten deswegen ja nicht verboten.
Ich habe das sehr wohl beim ersten Mal gelesen. Github ist für Webprogrammierer, die gemeinschaftlich an einem Projekt arbeiten, eine gute Einrichtung, um dies zu tun und sich untereinander auszutauschen.
Und der hat Röntgenaugen, mit denen er den Monitor meines PCs sehen kann. Daher weiß er auch, dass ich dort Gespenster gesehen habe, die ich heute ohne Zugriff auf dieses Feature nicht mehr sichtbar machen kann.
Wer denkt bei einer Homepage nur mit Text, dass es sich um einen Google Maps Ersatz handelt? Definitiv wäre ich so nicht zu OSM gestoßen. Die anderen Renderer habe ich erst wahrgenommen, als ich mich mit Hilfe von osm.org/Carto eingearbeitet hatte. Die vielen Mapper hätte es auch nicht gegeben und das Projekt hätte kaum Verbreitung gefunden. Aber ich denke, dass man irgendwann die Notwendigkeit erkannt hätte, dass man eine Beispielreferenz braucht, an der sich der Neuling intiutiv orientieren kann und nicht wie von Dir gefordert, mit einer abstrakten Datenbank zu arbeiten hat. Denn dann wäre das Projekt inklusive Mapper bis heute ein Tummelplatz von Nerds und kaum reinen Kartogarphen.
Wenn man sehen will, ob das gemappte Haus in der Karte erscheint, ist das kein Mappen für den Renderer und auch keines speziell für Carto. Es ist lediglich eine Fehlerprüfung, mit der man herausfinden will, ob man einen Fehler gemacht hat. So wird man darauf aufmerksam, dass man beispielweise “biulding” statt “building” geschrieben hat. Das ist nicht gegeben, wenn man es nur in die Datenbank lädt.
Wenn man eine Website erstellt, belässt man es ja auch nicht beim Hochladen des Codes in eine Datenbank, sondern testet auch anschließend, ob alles klappt.
Im Übrigen ist die Behauptung, dass wir nicht für den Renderer oder andere Anwendungen mappen, falsch. Denn gäbe es diese Anwendungen nicht, gäbe es auch kein OpenStreetMap.
Wir mappen vielmehr fast ausschließlich und bisweilen sogar optimiert für die Anwendungen. Wieso gäbe es sonst beispielsweise die Grundsatzdiskussion, ob der Straßenname an Radwege gehört, weil das in der Karte stört. Auch die Abbiegerelationen sind mundgerecht für den Navigator entworfen, obwohl man sie auch anders mappen könnte.
Mir ging es auch so. Aber bezüglich der Rendererkenntnis gibt es noch krassere Fälle:
Auf dem OSM Stand beim CCC sprach mich eine Gruppe Asiaten aus Myanmar/Birma an. Einige von ihnen hatten schon mehrere Jahre in OSM editiert. Sie gehen dazu auf osm.org, editieren dort mit ID und kehren dann zurück, um zu prüfen. Sie pendeln ausschließlich zwischen diesen beiden Websites und waren dann erstaunt, dass sie auf einmal einen anderen Kartenhintergrund sahen. Natürlich habe ich ihnen dann das “Ebenen”-Icon gezeigt. Darauf flippten sie, jetzt in ihrer Heimatsprache mit einem breiten Lachen im Gesicht aus. Sie wussten trotz ihrer langen Beteiligung an OSM nichts von anderen Renderen und hatten sich ausschließlich mit der Hilfe von osm.org sprich Carto das Editieren beigebracht und ausgeführt. Derart sensibilisiert, habe ich dann später weitere Mapper z.B. aus Afrika und auch aus Deutschland getroffen, die ebenso verfuhren.
Insgesamt kann man sagen, dass viele Mapper keine Foren und wenig Wiki lesen. Manche schauen sich an, wie beispielsweise ein Haus oder ein POI in der Hauptkarte aussieht und kopieren und modifizieren die zugehörigen Mappings. Dann schauen sie nach, ob ihr Haus so aussieht wie das kopierte Muster. Ohne eine solche Orientierung an Mustern kommen sie nicht zurecht.
Die Zoomstufen 0 bis 12 werden nur einmal im Monat am letzten Sonntag gerendert.
Das letzte Mal also am Sonntag, 29.08. Way 304926269 und andere wurden am Donnerstag, 26.08. geändert, drei Tage davor, die Änderungen müssten also gerendert sein.
Mit der Umstellung auf das Fastly CDN wurde auch die Zuordnung der Renderer umstrukturiert. Für z0-12 sind nun ausschließlich die Server scorch und albi zuständig. Die Last wird zwischen den Servern pro Tile-Request zufällig verteilt, deshalb sieht man bei unterschiedlichen Ständen ein gemischtes Kartenbild.
Das sieht man auch an den erwähnten HTTP Response-Headern, besonders schön wenn man in Chromium/Chrome in den Entwickler-Werkzeugen (F12) im Netzwerkanalyse/Network Tab per Rechtsklick auf die Kopfzeile “x-tilerender” als Custom Header zur Request-Tabelle hinzufügt (siehe Chrome Referenz).
Schaut man sich die Tiles direkt mit Server-Prefix an, sind die von scorch aktuell und die von albi nicht, z.B. (Live-Links):
Anscheinend gab es da Probleme und der Speicher bei albi reicht wohl nicht mehr für automatische Aktualisierungen aller niedrigen Zoomstufen aus. Obwohl der Server schon extra nur dafür abgestellt wurde, eben weil er nicht sehr leistungsfähig ist.
Für einen gezielten Test habe ich das Tile am anderen Ende, mit gleichem Status, per dirty-Request von albi manuell rendern lassen (bzw. das entsprechende Metatile = 8*8 Tiles):
OK, aus der Perspektive hast du natürlich absolut recht. Und ja: “Unsere” Karte ist halt nunmal primär die Referenz - nach außen - und für viele.
Aus den Beiträgen von mmd und ikonor entnehme ich, daß im Hintergrund ein starker Umbau der Infrastruktur im Gange ist. Ich habe zwar ein paar Ideeen aber bei dieser Gemengelage fehlt mir dann doch der Durchblick und das Wissen wo ich im Fehlerfall genau nachschauen muss.
Viel geredet… Ich bin hier raus.
Vielen Dank für den Einblick in die Serverstruktur, @ikonor. Vielleicht kannst Du hierzu einge Fragen beantworten:
Heißt das also, dass es die “/dirty”-Funktionalität immer noch gibt? Diese rendert zeitnah die betroffene Kachel auf dem prefixten Server neu und bringt somit ein aus welchen Gründen auch immer bisher noch nicht gerendertes Element zur Anzeige.
Für zukünftige Fälle: Gibt es auch eine dirty Anfrage, die auf alle Server der betroffenen Kachel und deren Zoomlevel wirkt? In diesem Falle wäre das also Albi und Scorch. Die würde somit auch dann funktionieren, wenn man nicht alle derzeit beteiligten Rendererserver beim Namen kennt.
Die von Dir mit dem “/dirty”-Feature gerendete und somit “reparierte” Kachel auf Albi zeigt jetzt dasselbe wie auf Scorch. Daher ist jetzt die Strg-F5-Anzeige im Bereich dieser Kachel inzwischen stabil und der Bug somit verschwunden, während er in den noch unterschiedlichen Kacheln noch existiert. Da die Kacheln auf osm.org mal von Albi und mal von Scorch geholt werden, wechselt die Anzeige bei jedem Strg-F5. Ist diese Kausalität richtig? https://www.openstreetmap.org/#map=12/54.6226/11.3269
Nach solch einer “Reparatur” auf Albi braucht es dann sicher noch einige Zeit zum Verteilen, bis alle User auf osm.org stabil dasselbe sehen. Hast Du hierfür die Vorstellung einer zeitlichen Größenordnung? Minuten, Stunden, Tage? Ich frage dies, weil das ja auch Grund dafür sein könnte, weshalb es zwischen dem Rendern auf Albi/Scorch bzw. Konsorten und dem Erscheinen auf osm.org lange braucht.
Wäre Albi so leistungsfähig wie Scorch, würden beide nahezu gleichzeitig (an dem besagten Sonntag) rendern, und es gäbe diesen Bug in z12 nicht. Sollte somit die in diesem Thread von mmd thematisierte, geplante Aufrüstung diesen Fehler eleminieren?
Diese ominöse /dirty Flag gibt es natürlich noch. Es ist eine Funktionalität von mod_tile (einem Apache Modul), das mit dem renderd interagiert und sich um die Priorisierung der Anfragen in mehreren Warteschlangen kümmert und auch gerenderte Tiles im Dateisystem zwischenspeichern kann. Die Projektseite beschreibt die verschiedenen Möglichkeiten ganz gut im Überblick: https://github.com/openstreetmap/mod_tile
Über die /dirty-Funktionalität kann man einzelne Kacheln auf genau einem Server in die “Dirty”-Queue einstellen. Diese Warteschlange ist eine Art Lumpensammler, der mit niedriger Priorität Kacheln neu rendert, wenn gerade nichts los ist. Von den 5 Warteschlangen ist die Dirty-Queue die Warteschlange mit der zweit-niedrigsten Priorität. Natürlich hat jede Warteschlange eine Obergrenze, und sobald die erreicht wird, werden auch keine neuen Anfragen mehr dort hinzugefügt.
Nun rate mal, was passiert, wenn man die Seite im Browser per Ctrl-Shift-R neu lädt? Richtig, man ist genauso weit wie mit /dirty. Deshalb meinte Tom auch, dass “/dirty” nicht wirklich Sinn macht und sich auch geweigert, diese Funktionalität nochmal in osm.org einzubauen.
Leider hat die ganze Warteschlangen-Verwaltung in mod_tile einige Probleme, die man mal angehen müsste (das sagte der Autor apmon zumindest in 2017): https://github.com/openstreetmap/mod_tile/pull/152#issuecomment-348805403. Das ist jetzt alles sehr technisch, aber es gibt wohl Szenarien, in denen Anfragen verworfen werden, die eigentlich nochmal in einer anderen Warteschlange später gerendert werden könnten.
Es gibt Leute, die meinen, nein das sei alles Quatsch, mod_tile funktioniert super. Keine Ahnung, ich habe das nicht mit dem Volumen von osm.org getestet.
Ja. Zum “/dirty” Flag schreibe ich ggf. später mal noch was.
Nein, die müsste auch schlau genug sein und unnötige zusätzliche Last vermeiden, also z.B. keine bereits aktuellen Tiles neu rendern.
Ja.
Das Rendering an sich dauert nur Sekunden, veilleicht auch mal Minuten bei niedrigen Zoomstufen
Wenn ein Server überlastet ist, landen Anfragen in der “Dirty”-Warteschlange (Queue), oder werden ggf. ganz verworfen, siehe auch Beitrag mmd. Oft wird die erst am Abend oder über Nacht abgearbeitet
Dann sind da noch die Zwischenspeicher (Caches) im CDN und Browser. Ein bereits zwischengespeichertes Tile wird erst wieder nach dessen Ablaufdatum aktualisiert, außer beim Neuladen ohne Cache mit Strg + Umschalttaste + R (von mehr Browsern unterstützt) oder Strg + F5. Das Ablaufdatum steht im HTTP Response Header “expires” und kann bis zu sieben Tage lang sein. Es kann also sein, dass es bis zu einer Woche dauert, bis alle User auf osm.org ein aktualisiertes Tile sehen.
Das ist aber alles nicht die Ursache für unser Problem hier. Bei z12 auf albi ist es wie gesagt, dass das Rendering nicht mehr durchläuft. Bei z13+ hab ich mal vor, die nächsten Tage noch zu schauen, ob mir was auffällt.
Genau. Hoffentlich, allerdings gibt es noch mehr schwache Server und ich weiß nicht, wie die neuen genau eingesetzt werden sollen. Aber die Admins kennen das Problem mit Albi ja, da können wir nur abwarten.
Meine Erklärung für nicht aktualisierte Tiles in den hohen Zoomstufen 13 bis 19 ist, dass sich in den entsprechenden Metatiles keine Nodes der geänderten Ways befinden und diese deshalb nicht als veraltet (expired/dirty) markiert wurden.
Obiges bezieht sich auf Metatiles. Auf den Renderern werden Metatiles erzeugt und gespeichert. Diese sind 8*8 = 64 Tiles groß, die einzelnen Tiles werden daraus ausgeschnitten.
Die Ways in diesem Fall sind gerade und haben jeweils nur zwei Zwischenknoten im Wasser (Overpass Turbo), bei den Schnittpunkten mit dem Naturschutzgebiet Fehmarnbelt (grün). Daher erhöht sich mit jeder Zoomstufe die Wahrscheinlichkeit, dass die Ways ein Metatile ohne Knoten schneiden, Zoom 13 und 14 sind entsprechend auch vollständig gerendert.
No tile could not be found at storage location: file:///srv/tile.openstreetmap.org/tiles/default/15/0/66/72/11/136.meta
Ruft man dann das fehlende Tile selbst auf, so muss es auf jeden Fall neu gerendert werden und ist auch vollständig:
Die Tiles oben und links davon sind in einem anderen Metatile und haben entsprechend einen aktuellen Status. Hier wird also gerade eine kleine Ecke ohne Nodes geschnitten. Und es hängt vom Zufall ab, ob ein solches Metatile auf einem Server schon existiert und mit altem Stand nur ausgeliefert oder mit aktuellen Daten erstmalig gerendert wird. Da im Wasser wenig sonstige Änderungen stattfinden, die ein Rendering auslösen, könnten solche Tiles ohne “/dirty” wohl eine ganze Weile so veraltet bleiben.
Das hier ist also ein eher seltener Sonderfall, den es schon immer geben konnte. Nur dass es durch die Mischung einzelner Tiles von mehreren Servern deutlicher auffällt und weniger nachvollziehbar ist.
PS: Ich habe mal z12 per “/dirty” vervollständigt.
Außer ein Carto Release kommt um die Ecke, wie jetzt gerade, dann werden komplett alle (Meta-)Tiles als veraltet markiert und bei Aufruf neu gerendert:
Vielen Dank an @ikonor und @mmd für die Recherchen und Erläuterungen.
Hmm, ich erinnere mich, wie Frederik vor zehn Jahren ermittelt hatte, dass jeder zweite Edit in Deutschland stattfände. Inzwischen dürfte ein europazentriertes Mappen doch schon seit Jahren der Vergangenheit angehören. Von daher sollte es immer irgendwo Tag sein und für die Server keine Nacht mehr geben, oder? Allenfalls wenn die Sonne mitten auf der Wasserseite also dem Pazifik steht, könnte der Traffic ein wenig abflauen.
Eine Alternative wäre es also, der schnurgeraden Strecke mehr Knoten zu spendieren. Aber das wäre dann Mappen für den Renderer, allerdings in einem anderen Kontext, als es üblicherweise gemeint ist.
O.K. Dann war meine Kritik in diesem Fall unberechtigt. Er fügte sich halt in die derzeitige Problemserie ein, so dass ich ihn damit in Verbindung brachte. Früher ist er auch deswegen weniger aufgestoßen, weil man das dirty Feature noch ohne diese eingehenden Kenntnisse nutzen konnte, um solche Probleme zu beseitigen. Denn offenbar funktioniert hier Strg-F5 nicht als Alternative.
Da hat Paul genau den richtigen Zeitpunkt erwischt. Allerdings erschließt sich mir nicht ganz, wieso manche Server die Routine Arbeit nicht schaffen und jetzt auf einmal nebenher die ganze Welt neu rendern können. Die einzige Erklärung wäre für mich, dass man die neuen Server integriert hat.
Die Probleme traten meist nur in Zusammenhang mit Carto Releases auf. Neu gerendert wird erst, wenn Tiles aufgerufen werden, nicht auf einmal (z13+). Durch die Aufteilung auf Regionen werden eben hauptsächlich die dortigen Tiles aufgerufen.
Wenn ich das richtig verstanden habe, dann wird ja einmal im Monat sowieso alles durchgerendert.
Wie kann das also sein?
Nach dem ich mehrfach den Browser-Cache gelöscht haben und mit F5 aktualisiert habe wird es besser. Nach dem ich das Spiel ca. 3 mal wiederholt habe, habe ich jetzt einen einheitlichen Stand.
Brower ist Firefox und ich lösche nach beenden immer automatisch den Browercache.
Was bedeutet das?
Es gibt wohl irgendwelche Tile-Caches die “den Schuß” nicht hören und erst händisch dazu ermutigt werden müssen sich die Daten frisch zu holen.
Oder?
OK, aber was hat denn bitte veranlaßt, die Bereiche gerendert wurden? Sie wurden ja nicht angefaßt/geändert.
…aber wenn Sie gerendert werden… Dann wenigstens von allen Renderserver? Das wäre ja Grundvoraussetzung für eine durchgängige Darstellung.
… und was ist mit den Tile-Caches? a) unterschiedliche Akualisierungs-Logiken? b) greifen auf verschiedene Renderserver zu?
Auf unterschiedlichen Ebenen und von Kachel zu Kachel erhät man völlig verschiedene Ergebnisse. Per Zufallsgenerator wird bestimmt was man bekommt. Einfach nur völlig banane!
Die Änderung der Darstellung vom Flächenstil zeigt die Problematik sehr deutlich. Nimmt man kleine Änderungen vor dann fällt das ganze halt nicht sofort auf. Und wenn es blöd läuft bekommt man nach 2 Wochen auf irgend einer Ebene immer noch Kacheln mit dem alten Stand geliefert.
…und das hat es früher nicht gegeben! Woran liegt’s?
Die Aktualisierung des Carto-Stils selbst, siehe #39.
Unterschiedliche Stände zwischen Metatiles und auf verschiedenen Zoomstufen hat es immer schon geben.
Neu ist die Lastverteilung für jedes einzelne Tile im Normalbetrieb und da fallen unterschiedliche Stände halt besonders auf.
Meiner Einschätzung nach daran, dass unter hoher Last nicht immer sofort gerendert werden kann und man deshalb vom einen Server noch alte, vom anderen schon neu gerenderte Tiles bekommt und diese durch die Lastverteilung bunt gemischt werden.
Dazu muss man betonen, dass Tiles auf den hohen Zoomstufen z13-19 nicht vorab gerendert werden. Nach einer Datenänderung oder einem Carto-Release werden die Metatiles nur als veraltet/abgelaufen markiert, aber nicht sofort neu gerendert. Das Rendering eines markierten Tiles wird erst beim nächsten Aufruf durch einen Benutzer angestoßen.
Unter hoher Last, besonders nach einem Carto-Release, können nicht alle Anfragen sofort “on-the-fly” gerendert werden, sondern manche landen in der Warteschlange für später (Dirty Queue) oder fallen ganz hinten runter. Dann wird erst mal noch ein altes Tile ausgeliefert.
Ich denke, das hängt von der aktuellen Auslastung und der Leistungsfähigkeit eines Servers ab. Zum Beispiel waren bei der Lastverteilung der stärkere Ysera mit dem schwächeren Necrosan kombiniert. Das wurde zwar durch eine ungleiche Verteilung berücksichtigt. Trotzdem war Necrosan mit dem aktuellen Carto-Release höher und länger ausgelastet und hat deshalb vermutlich auch öfters alte Tiles ausgeliefert als Ysera. Den Unterschied kann man gut an der Statistik der Dirty Queue (Gelb) sehen:
Wie man in den Diagrammen auch sieht, ist größte Last durch das Carto-Release inzwischen verarbeitet, im weiteren normalen Betrieb sollten solche Mischungen von neuen und alten Tiles eher selten vorkommen.
Warum die Lastverteilung auf der Ebene einzelner Tiles statt z.B. auf Session-Ebene gemacht wird, weiß ich nicht. Ich bin zwar kein Admin, aber für mich sieht das kurzfristig eher nach Multiplikation der Last als nach Verteilung aus, da das gleiche Metatile auf zwei Servern gleichzeitig gerendert wird, statt nur einmal.
Aber da sich gerade bei den Servern was tut und es voraussichtlich bald auch einen bezahlten Admin gibt, würde ich auch hier erst mal abwarten.
Das macht Mut.
