Wie augenblicklichen Stand von osm.org abrufen?

Die Unterschiede sieht man auch, wenn man sich die Kacheln direkt von unterschiedlichen Tile Servern (=Renderer, nicht der Cache) anfordert. Durch CDN kommen evtl. noch weitere Effekte dazu, das Problem hier lässt sich aber komplett auf Ebene der Tile Server betrachten.

Macht also am besten so ein GitHub Issue auf und lasst die Experten ran. Wildes Spekulieren hilft hier wirklich nicht weiter.

Da hast du mich gerade auf eine Idee gebracht… :slight_smile:

Der offizielle Tile-Server (das CDN) ist https://tile.openstreetmap.org, und eine Beispiel-Kachel: https://tile.openstreetmap.org/13/4249/2735.png

Wenn man das Gefühl hat, daß dort etwas nicht stimmt kann man das gegen die offiziellen Tile-Render-Server prüfen.

Die beiden Tile-Render-Server der OSMF: https://ysera.openstreetmap.org, https://odin.openstreetmap.org

Man nimmt die URL der Kachel und tauscht “tile” durch “ysera” oder /“odin” aus.

Dann weiß man zumindestens wo man suchen muß.

Frage in die Runde:
Funktioniert der /dirty /render-new (oder wie hieß der Parameter noch gleich?) noch? Und wie wäre die URL exakt?

Wäre es eine Option, daß über die Webseite (www.osm.org) angemeldete Benutzer sich optional Kacheln direkt von den Render-Server anzeigen lassen können?

mit dirty kann oder konnte man das Rendern anstoßen, mit /status sieht man wie das tile steht:

https://ysera.openstreetmap.org/0/0/0.png/status

die Zeiten sind natürlich UTC also derzeit +2h

Leider verstehe ich nicht, was Du hier tust und welchem Zweck es dienen soll. Welches Problem möchtest Du lösen?

Dieses nutzerfreundliche Feature gab es früher einmal: Rechtsklick in die Karte, dann “Kachel im neuen Tab anzeigen” (oder so ähnlich) im DropDown auswählen, und zuletzt “/dirty” an die Kachel-URL anhängen. Wenn ich mich recht erinnere, ging das auch ohne Anmeldung.

Keine Ahnung, warum man es wieder rausgeschmissen hat. Ich habe es schon schmerzlich vermisst, bringt aber wenig, wenn man den Effekt neuerdings auf osm.org nicht mehr überprüfen kann. Alles in allem wird das System für Otto Normalmapper immer unbenutzbarer. Aber das passt ja zu dem “winds of change”-Motto, das craft-mapping für nicht mehr erforderlich hält.

Möglicherweise wäre die von Dir ins Spiel gebrachte Anmeldung eine Möglichkeit, einen Server nur für diese Nutzergruppe anzubieten, der nicht durch die Abrufe externer Zugreifer überlastet ist und von daher das Fünf-MInuten Rendering wieder ermöglicht.

Tom, einer unserer Admins, hatte schon 2017 festgestellt, dass dirty praktisch nie notwendig ist, und die Leute irgendeinem “Kult” hinterherlaufen. “dirty” fällt also in die Kategorie “Schlangenöl”. Entsprechende Diskussion: https://lists.openstreetmap.org/pipermail/dev/2017-March/029766.html

Das passt irgendwie nicht dazu, dass die OSMF fleißig in weitere Renderserver investiert. Siehe https://operations.osmfoundation.org/2021/02/23/budget.html → Tile service capacity

Mir erschließt sich nicht so recht, was du prüfen möchtest? Es gibt doch diverse Renderer, auch offline (bspw. josm) die dir die Daten rendern. Oder geht es dir darum, dass du ein Objekt so mappen möchtest, dass es auf der Hauptkarte schön dargestellt wird?

Wenn wir das melden wollen, sollte man das Problem dann auch noch sehen können, deshalb:

Bitte vorerst keine dirty Requests ausführen.

Außer für einen gezielten Test und dann bitte vorher das Status-Datum notieren und mit Tile URL hier dokumentieren, damit das nachvollziehbar bleibt.

Wenn das was mmd geschrieben und verlinkt hat wahr ist, dann ist das mit dem “dirty” eh völliger Mumpitz. Im Prinzip gleich aus dem Kopf streichen.

Sollte das CDN nachvollziehbar ewig brauchen bis die Kacheln aktuell geliefert werden dann könnte man das der OSMF über github melden. Ich denke da gibt es tuning-Möglichkeiten auf Seiten des CDN. Wenn ich aber den verlinkten “budget” richtig interpretiere bekommen wird uns das CDN kostenlos zur Verfügung gestellt…

Mir erschließt sich nicht, wie jemand solch eine Frage stellen kann und warum das nicht selbsterklärend ist. Wenn man in einem Zeichenprogramm eine Linie zieht und die nicht erscheint, hat man entweder einen Fehler gemacht oder es funktioniert nicht. Hat man beispielsweise weiß auf weiß gezeichnet oder liegt der Fehler im Programm? Wenn das Zeichenprogramm im Web läuft, kann der Fehler auch darin bestehen, dass etwas nicht hoch- und wieder runtergeladen wurde. Dem einen ist es jetzt wichtig, das herauszufinden, dem anderen nicht, weil ihm andere Dinge wichtiger sind. Andere haben nicht das hierzu nötige Vorwissen. Man hat ihn als User des Programms verloren. Wenn man aber Nutzer für das Programm gewinnen will, sollte es einen so elementaren Fehler, dass korrekt gezogene Linien nicht gezeichnet werden, nicht geben, um zumindest diese Fehlermöglichkeit auszuschließen.

Ähnlich ist es bei OSM. Natürlich will man prüfen, ob man keinen Fehler gemacht hat. Es ist sozusagen der “Hallo World”-Test, der einem zeigt, dass man alles richtig gemacht hat. Das gilt insbesondere für weniger erfahrene Mapper. Wie kann man allen Ernstes voraussetzen, dass jeder Mapper weiß, dass es neben der Hauptseite weitere Darstellungen gibt, unter der er obendrein eine funktionierende suchen muss? Wie kann man allen Ernstes voraussetzen, dass ein Mapper weiß, was zu tun ist, wenn er auf der Hauptseite tausende Häuser eingezeichnet sieht, aber das von ihm eingezeichnete nicht? Wir brauchen eine möglichst niederschwellige, sicher funktionierende Hauptseite, um weitere Mapper zu gewinnen, von denen wir viiiiiiel zu wenig haben und die wegen solcher Vorfälle, wie hier beschrieben, weglaufen. Und ohne Mapper kann OSM einpacken.

Man stelle sich vor, jemand stößt auf OSM. Er hat noch nie in seinem Leben gesehen, dass es tatsächlich möglich ist, dass er etwas in einer Karte eingezeichnet, die man dann auf einer Website sehen kann. Er versucht also erstmals einen Edit. Wo guckt derjenige nach, ob es funktioniert hat - natürlich auf der Hauptseite. Dort erscheint sein Edit nicht - auch nicht nach Tagen oder Monaten. Er kommt zu der Erkenntnis, dass er das nicht hin bekommt oder dass es nicht funktioniert und wird kein Mapper. Dasselbe gilt für jemand, der schon editiert hat. Er ist dann kein Mapper mehr. Glaubst man wirklich, dass jeder die Eintragung des neuen Schuhladens für so wichtig erachtet und zudem das Wissen, Geduld und Engagement mitbringt, um solche Fehler zu umschiffen? - zumal es früher schon mal funktioniert hat?

Oder ich möchte jemandem, dessen Interesse ich beispielweise am OSM Stand oder per Mail wecken konnte, zeigen wie es geht. Viele empfinden schon das Editieren als anspruchsvoll - und das sogar auf dem Chaos Communication Congress. Soll ich denjenigen jetzt auch noch damit erschrecken, dass es viele Darstellungen von OSM gibt und er erst mal eine suchen muss, die funktioniert, damit er das soeben eingetragene Haus sehen und somit überprüfen kann? Von denen, die beim Editieren noch nicht abgewunken haben, werden die meisten das jetzt tun. Die Welt besteht eben nicht nur aus Naturwissenschaftlern und Webprogrammierern, die beispielsweise wissen, dass man eine URL manipulieren kann. Die große Mehrheit sind Leute, die in anderen Berufen arbeiten und tagsüber beispielsweise Brötchen backen oder verkaufen, LKW fahren oder Post ausliefern. Sie finden beispielsweise URLs nur über Suchmaschinen bzw. nehmen deren Existenz nicht wahr. Zu berufsfremden Mappern siehe auch OSM Podcast:
https://podcast.openstreetmap.de/2012/11/15/osm-talk-der-troisdorfer/

Wenn die Arbeit vieler Mapper und deren Helfer durch die Hauptseite behindert bzw. verkompliziert wird, die seit einundeinhalb Jahren nicht mehr vernünftig funktioniert und keine Einsicht dafür besteht, dies endlich mit höchster Priorität zu reparieren, dann ist das ein Zeichen, dass sie offensichtlich nicht mehr erwünscht sind. Da kommen auch bei mir nach über zehn Jahren so langsam Zweifel auf, ob das noch mein Projekt ist.

Ein weiteres Beispiel dafür, wie weit ein verantwortlichen Insider von dem abgehängt ist, wie ein einfacher Mapper denkt und somit ein weiterer Baustein fürs Verscheuchen.

Ich kann nicht beurteilen, inwieweit das zum Beheben des hier in Frage stehenden Fehlers genutzt werden soll. Ich kann nur sehen, dass die für Mapper höchstwichtige Hauptseite seit einundeinhalb Jahren nicht funktioniert und keine Maßnahmen - auch nicht Investitionen in Server - dagegen gefruchtet haben.

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.

Vielen Dank für diese Aufklärung. :slight_smile: Das macht Mut.

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.

Mehr Wahrheit war selten in einem Post! Meine Hochachtung.

Zoom 0-12

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.

z0-11 sind nicht relevant, da construction erst später gerendert wird: highway=construction >= 12, railway=construction >= 13.

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):

scorch:

https://scorch.openstreetmap.org/12/2177/1302.png/status:

Last rendered at Sun Aug 29 13:09:28 2021.

albi:

https://albi.openstreetmap.org/12/2177/1302.png/status:

Last rendered at Thu Jun 17 15:40:53 2021.

Laut Status wurde albi zuletzt am 17. Juni aktualisiert. Das passt zu einem Issue aufgrund dessen das Rendering in diesen Tagen manuell angestoßen wurde:
operations#539 Town name displayed inconsistenly in adjacent tiles

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):

https://albi.openstreetmap.org/12/2176/1304.png

Das hat schon funktioniert.

Das alles gilt in diesem Fall nur für z12, bei z13+ muss es noch eine andere Ursache geben.

… und …

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. :slight_smile: Vielleicht kannst Du hierzu einge Fragen beantworten:

  1. 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.

  2. 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.

  3. 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

  4. 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.

  5. 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.

  1. Das Rendering an sich dauert nur Sekunden, veilleicht auch mal Minuten bei niedrigen Zoomstufen
  2. 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
  3. 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.