Guck nochmal näher hin: 
–ks
“1 bis 10” nicht “1 minus 10”, sprich 1 bis 10 Milliarden um einen konkurrenzfähigen, offenen Dienst aufzubauen, d.h. Karte + Luftbild + Strassenansicht, und ein bisschen zu betreiben (längerfristig gibt es in so einem Szenario dann keine Konkurrenz mehr, und man kann als unabdingbarer Dienst leichter um Geld betteln).
Den Gedanken finde ich gut. Universitäten, die OSM nutzen, können einen Kachelserver in ihrem Rechenzentrum anbieten. Für Repositories von Linux-Distributionen wird genau sowas gemacht. Soweit ich weiß, können Universitäten nicht einfach mal einen Betrag spenden, aber ein Beitrag in Form eines Kachelservers müßte möglich sein.
Ups, danke, jetzt mit meiner Lesebrille und dem extra Hinweis sehe ich’s auch. Das könnte man doch von Zeit zu Zeit an prominenterer Stelle plazieren, z.B. in dem Infofensterchen links oben auf osm.org. Wikipedia ist mit der Spendenkampagne immer recht aufdringlich, aber ganz so verstecken sollten wir die Möglichkeit nicht.
Wenn man sich da mal weiter durchklickt, kommt man aufdie vorläufige Einnahmen/Ausgaben-Rechnung fürs erste Halbjahr 2019. Es steht keine Einheit dabei, ich vermute mal GBP (Britische Pfund). Das verstehe ich so, daß es 4100 Spenden mit zusammen 9358 Pfund gab.
Mit etwas mehr Werbung könnte das zu steigern sein.
Tatsächlich da ist doch ein kleines Herzchen.
Bei der Wikipedia konzentriert man sämtliche Aktivitäten zu einem Portal, in diesem darf man dann einen Bildschirm breiten Banner weg klicken.
Wir leisten mit UMap, Maptiler und anderen ausgelagerten Projekten, das genaue Gegenteil: https://photos.app.goo.gl/fSoGGBgsiG7ue9xS9 Wir leisten uns ein Karusell welches beständig unsere Synergien fragmentiert.
Man könnte ausgelagerte Projekte -ab einer gewissen Größe- höflich dazu auffordern, jeweils prominent auf die OpenStreetMap Spendenseite hinzuweisen. Oder gleich den Spendenaufruf in unserem Lizenzhinweis c OpenStreetMap Donate unterbringen. Zum Beispiel mit einem Klick Banner hier: https://www.openstreetmap.org/copyright gezielt plazieren.
Selbst ein 99 Jähriger https://www.theguardian.com/world/2020/apr/16/coronavirus-capt-tom-moore-raises-12m-nhs-completes-garden-walk schafft es heute Spenden zu sammeln.
Einem Projekt mit inzwischen golbaler Bedeutung wie OpenStreetMap, sollte bei entsprechender Aufforderung das ebenso mit Leichtigkeit gelingen.
Edit+ CaptTom 99 Jahre
Leuten auf die Nerven gehen ist natürlich die Lösung…
Wenn die integriert wären, hätten wir genau das selbe Problem. Abgesehen davon sind Deine Beispiele ziemlich schlecht gewählt, bei umap kann man auswählen wo die Kacheln herkommen und maptiler verwendet, soweit ich weiss, gar keine .org-tiles.
umap ist ein gutes Beispiel, da mit diesem Tool ausgelagerte Pois, anschließend nur auf umap weiter administriert vom osm Kernprojekt abzweigen.
“bleibtoffen” basiert auf maptiler, wobei Claas für Korrekturen vorbildhaft zurück auf unser Kernprejekt verlinkt .
Habe ich das richtig verstanden: mehr Tileserver sollen ein Problem lösen, dass durch einen zu komplexen Mapnik Style verursacht wird?
So nach dem Motto: “Ein Schiff braucht 7 Tage von Hamburg nach New York. 7 Schiffe schaffen es an einem Tag”?
Mit ausreichend Geld, kannst Du durchaus auch was am Schiff verbessern, oder was noch besseres als Mapnik konzipieren. https://www.youtube.com/watch?v=U_ZcgdC6SSU&feature=emb_logo
Nein. Denn wenn es ev. auch einen Anteil “zu komplex” vor ein paar Wochen gab ist das schon längst gegessen, dass Problem aktuell ist schlicht Überlast des Cache Netzwerkes durch immer mehr Leute die die Kacheln verwenden, sprich also so wie immer.
OK, das ist beruhigend. Dann würde ich vorschlagen, anstelle von grauen Kacheln einen Text zu rendern, der auf die Möglichkeit der Spende hinweist. So was wie : “Hier fehlt uns leider das Geld” oder “Schade, wir haben nicht genug Rechenleistung”
Die Idee finde ich auch am Besten. Ich hatte mir schon überlegt, je nach Abfragendem die ganze Seite mit einem Banner zu überlagern; sowas wie
“Sie sind ein kommerzieller Nutzer unseres kostenlosen Dienstes und verursachen hohe Kosten. Durch eine regelmäßige Spende werden Sie dieses lästige Banner los.” 
Angemeldete Benutzer auf osm.org sehen das nicht.
Ein Sysadmin meinte gestern auf Rückfrage, es seien in Deutschland im Laufe dieser Woche einige Server dazugeschaltet werden und das Problem sollte daher im Moment im Griff sein. Entspricht das euren Eindrücken oder gibt es unverändert Probleme?
Ich habe seit Samstag nach dem Carto v5.1.0 Release täglich einzelne Tests gemacht und hatte schon den Eindruck, dass es seit Mittwoch deutlich besser ist.
Allerdings sehe ich gerade eben wieder Totalausfälle mit 504 timeout Fehler nach 2 Minuten.
Ich beobachte folgenden witzigen Effekt: Wenn ich einen CS hochlade und wenige Minuten später die Hauptkarte unter osm.org aufrufe, sind meine Änderungen zumindest in einzelnen Tiles, meist aber in allen betroffenen, bereits gerendert. Rufe ich aber denselben Bereich eine oder drei Stunden später wieder auf, sehe ich die alte Version. Auch Neuladen vom Server (Strg-F5) ändert nichts.
Aktuell habe ich z.B. in der Wiese um https://www.openstreetmap.org/#map=17/50.12663/8.25097 einige Feuchtgebiete gemappt.
Für mich heißt das: Gerendert wird zügig, gecachet wird schleppend (Caching-Server haben noch lange einen alten Stand).
–ks
Es hat aktuell 7 verschiedene Renderingserver, einer oder ein paar davon dürften einfach noch nicht so weit sein.
Bei mir ist jetzt alles grau 
Dann bekommst du sicher bald “neue” …
Grundsätzlich ist es hilfreich, wenn eine Fehlermeldung “graue Kacheln” möglichst präzise ist. Wann wurden vom von wo aus graue (oder eben keine, oder nur sehr langsame) Kacheln geliefert, welche Fehlermeldung gab es genau, und vorallem auch: Wann hat es gut funktioniert? Sicher sind nicht alle in der Lage, überhaupt so genau zu diagnostizieren, aber für die, die sich dafür interessieren, hier ein paar Hinweise.
Zunächst einmal kann man in den meisten Browsern eine “Entwickler-Werkzeuge-Ansicht” öffnen und dort einen Netzwerk-Monitor anschalten. Da sieht man, welche Anfragen der Browser an den Server schickt, und wie lange die Antworten gebraucht haben (oder ob es eine Fehlermeldung gab).
Da sieht man oben rechts auch (“remote address”), welche Server diese Anfrage bearbeitet hat. In meinem Beispiel ist das der Server 195.201.226.63. Wer “whois” und “traceroute” kann, der sieht, dass dieser Server bei Hetzner steht; das DNS verrät mir, dass der “keizer.openstreetmap.org” heisst. (Ich könnte auch in der Liste aller für Deutschland verwendeten Caches unter https://github.com/openstreetmap/dns/blob/master/src/tile.openstreetmap.yml#L155 nachsehen und dort die IP-Nummer finden).
Details über den Server, der mich bedient hat, finde ich dann auf https://munin.openstreetmap.org/openstreetmap.org/keizer.openstreetmap.org/index.html - dort kann ich eventuell schon erahnen, falls ich gerade einen schlechten Service hatte, woran das lag. Hier zum Beispiel sehe ich, wie viele Anfragen der Server insgesamt beantwortet (eine hereinkommende Anfrage landet zuerst beim “nginx”):
https://munin.openstreetmap.org/openstreetmap.org/keizer.openstreetmap.org/index.html#nginx
Zum Zeitpunkt dieser Nachricht waren das im Durchschnitt 450 pro Sekunde über die letzte Woche. Wenn der nginx den Request nicht selber beantworten kann, geht er an den Squid
https://munin.openstreetmap.org/openstreetmap.org/keizer.openstreetmap.org/index.html#squid
das sind im Durschnitt nur noch 120 pro Sekunde, d.h. 330 pro Sekunde federt der nginx direkt ab. Von den 120 pro Sekunde, die beim Squid ankommen, sind ca. 80 “cache misses” und werden an den Renderingserver weitergereicht.
https://munin.openstreetmap.org/openstreetmap.org/keizer.openstreetmap.org/squid_icp.html
Hier sieht man, welche Rendering-Server von diesem Cache angesprochen werden - in meinem Fall “germany.render.openstreetmap.org” (IP: 130.117.76.15, Standort: Amsterdam). https://github.com/openstreetmap/dns/blob/master/src/hosts.js verrät mir, dass der Server “odin” heisst, und ich kann dann wieder auf https://munin.openstreetmap.org/openstreetmap.org/odin.openstreetmap.org/index.html schauen, wie die Last auf dem Renderer so aussieht.
Das ist alles ein bisschen mühevoll, aber auch sehr interessant; man kann mit ein bisschen Arbeit nachvollziehen, wo genau es eigentlich gerade “hakt”, und so natürlich auch eine bessere Fehlermeldung produzieren.
Bye
Frederik
Noch als Ergänzung (siehe auch #69 und Gray tiles Issue Kommentar):
Im Netzwerkanalyse/Network Tab in den Entwickler-Werkzeugen (F12) gibt es in den Details zu einer Tile-Anfrage (Zeile klicken) unter “Antwortkopfzeilen”/“Response Headers” zwei Einträge, die Auskunft über den verwendeten Cache- und Render-Server geben:
- “x-cache” = Cache Server
- “x-tilerender” = Render Server
In Chrome kann man diese Custom Header per Rechtsklick auf die Kopfzeile auch direkt zur Anfrage-Tabelle hinzufügen (siehe Chrome Referenz), das sieht dann z.B. so aus ¹:
¹ Screenshot vom 27.02.2020 16:28 (UTC), siehe Gray tiles Issue Kommentar
Edit: Beschriftung Screenshot ergänzt
Ich nehm das zurück und behaupte das Gegenteil, ich nehm an woodpeck schreibt noch was dazu.