Graue Kacheln in OpenStreetMap.com

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?

Verstehe ich das richtig, dass es in den Gebieten, in denen die erholten Server ausliefern, jetzt problemfrei läuft? Gibt es da konkrete Rückmeldungen?

Wenn ich es richtig sehe, ist odin der für Deutschland zuständige Server. Und da sehe ich seit dem 11. Februar keine Lila Kurve unter rendered throughput.

Ich habe keine Aktien im Kachelserverbetrieb. Gibt es keine Möglichkeit, diese Erholphase aus dem Produktivbetrieb zu verbannen? Zwei Lösungsansätze fallen mir da ein.

Ist es möglich, ein solches Update zunächst in den bewohnten Gebieten auf einem nicht produktivem Server vorzurendern, und dann auf die weltweiten Server zu kopieren? Möglicherweise muss man für das Kopieren eine angekündigte Wartungspause ansetzen.

Oder wäre es eine mögliche Option, während eines Updates jeden Kachelserver temporär doppelt vorzuhalten? Auf einem läuft die alte Version ausliefernd und auf dem anderen die neue. Erst nach erfolgter Erholung wird auf den neuen Satz umgeschalten. Ich könnte mir vorstellen, dass dann die Wartungspause so kurz wird, dass man sie nicht ankündigen muss.

Also bei mir wird’s nicht besser mit den grauen Kacheln. Das halte ich für untragbar, mit so einem Kartendienst als Projektpräsentation blamieren wir uns im Netz doch kolossal. „OSM ist zwar detaillierter, aber was nützt mir das, wenn nix kommt“.

Was kann man tun?

–ks

Ich finde auch, dass das eine Schande ist.

Man könnte sich bei Joseph Eisenberg, dem derzeit aktivsten Carto-Maintainer und direkten Verantwortlichen für die problematischen Änderungen, beschweren.

Vorher wurde die Textpositionierung in Mapnik (C++) gemacht, jetzt wurde sie auf den PostGIS-Befehl ST_PointOnSurface, d.h. in der Datenbank, umgestellt. Für die beiden normalen Nutzungsarten a) Rasterkacheln b) Vektortiles mit Mapbox-GL aus externen Dateien bietet die Änderung meines Wissens keinerlei Nutzen.

Der Bibliotheksaufruf mag bei komplizierten Umrissen bessere Ergebnisse liefern und im Programm besser wartbar sein (da nichts selber programmiert werden muss), aber ob das den Performanceeinbruch rechtfertigt …

Ich finde die Argumente in dieser Diskussion dazu schon überzeugend, gerade in Bezug auf Vektortiles. Auch bei Raster hat die Idee schon ihren Charme, dass die Punkte für die Beschriftung festgelegt sind und nicht davon abhängen, welches Stück einer Fläche gerade in dem bearbeiteten Metatile liegen.

Ob die Verbesserung den Performanceverlust Wert ist oder man das Problem mit einer Ladung Indexe einfach lösen kann, weiss ich auch nicht …

Ich hab mir vor längerer Zeit einen anderen Kachelserver dafür eingestellt, läuft prima, allerdings finde ich die Einstellung nicht mehr in JOSM.
Ich vermute es ist slippy_map_choser.mapstyle

Ja is gerade nicht so toll… Wie schon geschrieben weiche ich auf andere Stile aus… Aber leider ist das nicht überall möglich :frowning:

Wenn ich der einzige bin, der sich beschwert (und sonst sehe ich da nix), dann kloppt der das ganz schnell in die Tonne :slight_smile: wofür ist einklich die OSMF da? Nur für die Datenbank, nicht auch für das Frontend?

–ks

In den Statistiken des Renderservers odin, der u.a. für Deutschland zuständig ist, ist mir die “Dirty queue” bei “Renderd queue length” aufgefallen, die sich letzte Woche erholt hat, aber seit gestern wieder erneut stark angestiegen ist:

https://munin.openstreetmap.org/openstreetmap.org/odin.openstreetmap.org/renderd_queue.html

Hab aber keine Ahnung, warum.

Es handelt sich um eine Geometrieberechnung in der Datenbank, die halt sehr häufig für jedes Polygon mit Namen ausgeführt werden muß. Da ist ein Index völlig nutzlos. Indexe helfen nur beim schnellen Auffinden von Daten, wenn diese Funktion genutzt wird, hat die DB die Daten bereits geholt.

Das einzige was hier helfen würde ist der Upgrade der Datenbank auf die aktuelle Version, in der diese Funktion optimiert wurde und ohne Leistungsverlust funktioniert.

Diesen Kartenstil auf Server mit einer alten Datenbank zu werfen ist schlichtweg ein Fehler. Ich würde wetten, daß auf dem Entwicklungsserver die allerneuste DB-Version installiert ist und man einfach übersehen hat, daß die Produktivserver ganz anders aussehen. Und es ist in den Tickets nachzulesen, daß man sich durchaus bewußt war, wie langsam die neue Methode ist und es trotzdem durchgezogen hat.

Fehler können immer mal vorkommen. Das einzige was ich nicht verstehe ist daß ein massiver und unnötiger Leistungsverlust seit zwei Wochen niemand von den Verantwortlichen interessiert. :frowning:
In dem betreffenden Ticket werden alle Problemmeldungen immer wieder abgewiegelt. Derzeit werden die grauen Kacheln auf Cacheprobleme geschoben obwohl die “attempted render” und “dropped tiles” in den Serverstatistiken eindeutig zeigen, daß die Render Server exakt seit dem Update ein Problem haben.

Wenn es mein Murks auf meinem eigenen Server wäre, würde mich sowas echt ärgern und wäre spätestens am nächsten Wochenende behoben.

Es gibt korrespondierende Zacken bei Apache und Firewall Durchsatz. Sieht so aus als ob einfach mehr Tiles von außen abgefragt werden - und wie gesagt: Durch den neuen Stil ist der Server jetzt dauerhaft etwas langsamer in der Abarbeitung geworden, eine Last die vorher nur “ziemlich hoch” war könnte jetzt zuviel sein.

ST_PointOnSurface ist kein Nice-to-Have, sondern eine Notwendigkeit für Vektortiles. Sonst gibt es das hier:

Die Debatte in https://github.com/gravitystorm/openstreetmap-carto/issues/1644 ist etwas zerfasert, aber soweit ich das verstehe ist ST_PointOnSurface nicht zwangsläufig besser, aber definitiv mehrfach langsamer.

Pferdekutschen haben auch ihren Charme, trotzdem fahr ich lieber Auto :wink:

Heute, Donnerstag 20.02. 4:30 Uhr lief alles glatt wie in früheren Zeiten. Nichtdestotrotz könnte darüber nachgedacht werden, wie sich solche Vorkommnisse z. B. durch parallele Testläufe auf nichtproduktiven Servern vermeiden lassen. Ich werde versuchen, auf der nächsten Fossgis Konferenz, die kommenden Monat stattfindet, Ansprechpartner zu finden.

Ist von den am Thread Beteiligten noch jemand dort?