Graue Kacheln in OpenStreetMap.com

Ich wundere mich grade, dass openstreetmap.com genannt wurde, aber das gibts tatsächlich. Es ist eine Weiterleitung auf openstreetmap.org.

Ja, ich hab auch mehrfach graue Tiles.

Hier https://munin.openstreetmap.org/mod_tile-week.html scheint es die letzten 3 Tage höhere Latenzen zu geben, aber ob das die korrekte Statistik ist kann ich nicht sagen…

Glaub ich auch… nur kommt der mit dem rendern nicht hinterher :confused:

Ich weiche aus:
https://www.openstreetmap.de/karte.html
http://layers.openstreetmap.fr/

Ja! Egal ob mit Vivaldi oder Firefox unter Windows 7 (Ja, - ich weiß … :roll_eyes:) !

Es ist jedenfalls ätzend und macht keinen Spaß zur Zeit …

Peer

Drüben in der Wikipädie sind an so was immer die Hamster schuld. Ob die OSM-Server auch von Hamsterlaufrädern angetrieben werden, weiß ich persönlich nicht :slight_smile:

–ks

Könnte es eventuell ein Zusammenhang mit dem hier erwähnten Problem geben?
https://lists.openstreetmap.org/pipermail/dev/2020-January/030873.html

Vielleicht wird trotz Geschwindigkeitsbegrenzung für die Planetfiles die 1Gps-Grenze immer noch überschritten und es wirkt sich auf der Auslieferung der Kacheln?

Ich habe keine Ahnung, ob es wirklich so ist. Ich stelle mir nur vor, dass es eine Erklärung sein könnte.

In den Statistiken in #3 kann man unter “freshness” in den letzten Tagen einen gelben Streifen “old, attempted render” erkennen. Das bedeutet daß das Neurendern von Tiles angestoßen wurde, aber nicht geklappt hat oder zu langsam war und erst nach dem Timeout für den User stattfand. In so einem Fall sieht der Nutzer dann alte oder graue Tiles.

Das ist nach meiner Erfahrung immer ein Hinweis auf ein Problem beim Renderserver. Entweder ist das Rendern durch eine Überlastsituation zu langsam oder wahrscheinlicher gibt es einen Fehler in der Datenbank oder in den Renderregeln, die das Rendern mit einer Fehlermeldung fehlschlagen lassen. Der Renderer bleibt in so einem Fall hängen und kann einen Renderslot für mehrere Minuten blockieren bis er wegen Timeout abgeschossen und neu gestartet wird. Dadurch können auch Fehler, die nur bestimmte Objekte oder Regionen betreffen, schnell einen ganzen Renderserver blockieren.

Wenn es ein Update der Renderregeln gab (siehe #2), enthält es höchstwahrscheinlich einen Fehler.

Wird da eigentlich hinter den Kulissen dran gearbeitet, diesen Mangel zu beheben?

Ja, hier: https://github.com/openstreetmap/chef/issues/264 und https://github.com/gravitystorm/openstreetmap-carto/issues/4009

update (bzw. kein update):

Es scheint seitens der Maintainer etc. kein Handlungsbedarf gesehen zu werden. Die sagen “das ist normal, wenn ein neuer Style deployed wird” und es wird also erstmal abgewartet.

Tatsächlich hab ich auf den Grafiken im April 2019 ähnliche Spitzen gesehen, d.h. es könnte eine normale Situation sein.

Eine neue PostGreSQL/PostGIS-Version bringt wohl Performancevorteile, aber das bedingt einen vollen Reimport des Planetfile, und daher (und weil man in dem Zuge größere Neuerungen plant, z.B. hstore-Columns) dauert der Reimport noch etwas.

Da sind die Maintainer IMHO ein wenig optimistisch oder haben nicht in die Munin Renderstatistiken geschaut. Auch wenn die Server sich irgendwann wieder einpendeln sollten, geht aus denen hervor, daß die Anzahl der dropped tiles (=graue Kacheln) bei den übelsten Fällen im vergangenen Jahr nur halb so groß war wie aktuell. Es wird in der Diskussion darauf hingewiesen, daß die Hauptkarte derzeit einen schlechten Eindruck auf die Nutzer macht, aber das scheint nicht zu interessieren.

Ich würde eher sagen, daß hier etwas voreilig gehandelt wurde. Die Aufgabe “Platzieren von Labels auf Flächen” wurde vermehrt vom Mapnik-Renderer auf die Datenbank umgestellt. Diese Funktion ist aber nur in den neusten PostGIS Releases optimiert - in den Datenbankversionen, die die OSM-Renderserver verwenden, ist sie wohl bekanntermaßen deutlich langsamer. D.h. bis zu einem (sehr aufwändigen) Update der Datenbanken wird die Renderperformance insgesamt und dauerhaft reduziert.

Das ist eigentlich das Gegenteil von dem, was man üblicherweise mit einem Renderserver anstrebt. :frowning:

Danke für die Rückmeldung.

Kann es sein, daß es immer schlimmer wird mit dieser grauen und/oder unscharfen Kachelgeschichte?

Kann es sein, dass man durch einen missglückten Upload, gelegentlich selbst graue Kacheln verursacht.
Einmal hat bei mir ein Revert sowie anschließend erneutes Hochladen, eine punktuelle Epidemie in Grau wieder beendet.
Grüße Johann

Das grau kommt (auch) daher, dass wegen des Style-Updates ja alle Kacheln neu gerendert werden müssen. Der Prozess dazu ist (grob gesagt und aus der Erinnerung), das alle Kacheln als “dirty” markiert werden, aber in eine Hintergrund-Warteschlange eingereiht werden, die “Berechne diese Kacheln neu, wenn Du nichts anderes zu tun hast” sagt.

Wenn du jetzt die Daten, die in eine Kachel eingehen, änderst, und die Kachel deswegen neu berechnet werden muss, kommt sie aber in eine anders (nämlich höher) priorisierte Render-Warteschlange.

Er rendert also erstmal die Kacheln, die wegen Datenänderungen neu gerechnet werden müssen (denn die enthalten ja alte Daten), und wenn er die alle weg hat erst dann rendert er die Kacheln, die wegen des Stil-Updates neu müssen (denn die haben ja nur die alte Darstellung, die Daten dahinter sind ja aktuell).

Danke Gormo, für die Information.

Allerdings egal wieso, weshalb, warum (die technischen Prozesse im Hintergrund verstehe ich eh nicht), - das war doch bis vor ein paar Wochen NICHT vorhanden dieses Problem. Und ich empfinde es so, als ob es immer schlimmer wird.

Mein Eindruck ist, dass es jedenfalls nicht (wieder) besser wird. Wenn ich ein paarmal hin- und herzoome oder verschiedene Kartenausschnitte abrufe, sehe ich bald eine Menge graue Kacheln. Das war früher schon (oft) bei der OpenTopoMap so, die (nehme ich an) auf einem schwächeren Server residiert; dass sich jetzt auch openstreetmap.org so verhält, trotz aller Spiegelserver usw., ist mir neu.

Vor ein paar Wochen wurde auch nicht der Stil geändert.

Zum üblichen “eine Kachel muss neu gerendert werden, weil jemand hat da ein Haus gemappt” kommt bei Stiländerungen noch “alle Kacheln müssen neu gerendert werden, weil wir wollen alle Häuser jetzt in einer anderen Farbe darstellen”.

(“Haus” ist ein willkürliches Beispiel und aktuell scheint es eben auch so, dass zusätzlich der neuere Stil dem Renderer mehr Arbeit macht als der Stil davor)

Bisher waren nach einem Stil-Wechsel nach kürzester Zeit wenigstens die low zoom tiles brauchbar. In Mittelamerika ist die interaktive Karte von JOSM seit Tagen reiner Blindflug.

Baßtölpel

Das ist also der Preis, damit wir unsere Edits schnell dargestellt erhalten.

ich würde ja gerne eigene Rechenzeit zur Verfügung stellen. Z.B Skype funktioniert mittels verteiltem Rechnen.
Vielleicht mittels JOSM Plugin?

Wie bereits weiter oben geschrieben:

  • das Stil-Update hat das Anzeigen der meisten Namen von Flächenobjekten auf eine deutlich langsamere Technik umgestellt. Das heißt Neurendern dauert ab jetzt immer länger.
  • wie man in der Serverstatistik [1] sehen kann, sind Größe und Dauer des Rückstaus diesmal doppelt so hoch wie nach den anderen Stil-Updates im ganzen letzten Jahr.
  • Die schnelleren Server haben sich mittlerweile erholt, aber vier der Server noch nicht und verlieren immer noch Kacheln.

[1]
Tilestatistik: Gelbe und lila Bänder unter “freshness of tiles” zeigen die Versuche, Tiles neu zu rendern
Renderstatistik : Lila Kurve unter rendered throughput zeigt die abgebrochenen Renderversuche

Frage, gibt es für uns Mitwirkende besonders empfehlenswerte Arbeitsstrategien.

Z.B eine Region statt großflächig eher nur punktuell zu bearbeiten. In letzter Zeit verkleinere ich bei der Einarbeitung neuer Luftbilder, zugleich Multipolygon Strukturen und versehe diese hierbei mit einem geschlossenen äußeren Ring.

Wie wirkt sich solches auf das Rendern aus?