Hi, kann das an dem neuen Kartenstil liegen, dass dieser Bahnsteig, den ich gestern Mittag bearbeitet hab, auf den Stufen 18 und 19 nicht mehr gerendert wird?
https://mc.bbbike.org/mc/?lon=6.21651&lat=50.794362&zoom=18&num=2&mt0=geofabrik-german&mt1=mapnik&marker=
Grüße
Admin Edit: Abgetrennt vom Thread OSM-Carto 4.2.0 … Wasser wird blauer und hier ab #19 neu gestartet.
Möglich. Ich vermute aber eher, es liegt am Multipolygon. Der sichtbare Bahnsteig daneben verwendet ein normales Polygon.
Das ist dann aber ein Käfer im Renderer. Warum sollte der ein MP in höheren Zoomleveln ignorieren?
–ks
Ups, Du hast recht. Ich hatte mir nur die tiefste Zoomstufe angeschaut. Damit ist ein Renderer Bug in der Tat eher wahrscheinlich. Die oberen Level könnten allerdings auch noch auf den alten Daten vor der MP Änderung basieren. Wie weiss man, welche OSM Daten der Renderer für bestimmte Level verwendet hat?
Das erklärt aber auch nicht, warum andere Multipolygone gerendert werden: http://www.openstreetmap.org/relation/5151597#map=18/50.76687/6.09056&layers=N
Ich finde jetzt auch nichts, was meinem Bahnsteig noch an zusätzlichen Tags fehlen könnte, die relevant wären.
Grüße
Tagging sieht ok aus. Daten gerade heruntergeladen und selbst gerendert mit aktuellem Carto, Level 18 + 19 ok:
Vielleicht ist die Relation beim Replizieren in die Render-DB vergessen worden?
Ich würde noch geduldiger sein. Mit der letzten globalen Stiländerung hatte der Renderer viel zu tun und hinkt aktuell etwas hinterher (siehe Wochenverlauf seit 26.8. https://munin.openstreetmap.org/openstreetmap/render.openstreetmap/renderd_queue.html)). Wenn ich es richtig lese, wurde die Kacheln des Bahnhofbereichs, z.B. https://b.tile.openstreetmap.org/19/271197/175994.png/status, am 28.8 (gestern) um 19:00 Uhr zuletzt gerendert. Sollte die fehlende Darstellung aber dauerhaft bleiben kann ein Neurendern z.B. durch leichtes Verschieben eines Punktes erreicht werden.
Grüße
Andreas
Tut’s nicht auch ein „mark as dirty“ im Kontextmenü der Fullscreen Map? Nodes verschieben, um Neurendern auszulösen, ist letztlich auch Mappen für den Renderer 
–ks
Sorry, konnte mich aus Neugier nicht zurückhalten und habe das Rendering durch Verschieben von zwei Punkten (Baum und Treppe), die nicht Bestandteil des Bahnsteigs sind, neu ausgelöst, d.h. in der OSM-DB waren die Daten richtig drin. Die Kachel war aber noch veraltet. Jetzt sollte die Darstellung passen.
Ich habe da so eine Theorie:
28.8.2017, 18:55 UTM: hsimpson erstellt im CS51519054 das MP #7518879 ohne railway=platform und entfernt railway=platform vom Outer => es gibt nix mehr zu anzeigen
28.8.2017, 19:00 UTM: Die Kachel wird neu gerendert und somit kein Bahnsteig mehr dargestellt
28.8.2017, 19:05 UTM: hsimpson ergänzt im CS51519209 am MP das railway=platform, ohne dass die Geometrie oder die Outer/Inner-Tags geändert werden. Ich denke, dass dies nicht ausreichte, dass der Renderer die Kachel als Dirty eingestuft hat. Dies ist meiner Meinung nach so ein Fall, bei dem man am Einfachsten die Geometrie etwas ändert (z.B. einen Knoten leicht verschieben) und dann klappts mit dem Rendern.
Grüße
Andreas
@kreuzschnabel: /dirty funktioniert glaube ich nicht mehr und daher empfehle ich eine Änderung eines sichtbaren Objekts. Kann mich da aber auch täuschen und /dirty klappt doch noch.
Du hast recht Andreas, langsam werden die ersten Kacheln neu gerendert 
Verwunderlich war nur, dass die Kacheln das erste mal (ohne das railway=platform) nach wenigen Sekunden gerendert waren. Daran hab ich ja dann auch gemerkt, dass ich was vergessen hatte. Und danach kam dann gar nix mehr.
Vieleicht setzt der Server bei einer solchen Menge an neu zu rendernden Kachel ein blockierelement für grade neu gerenderte Kacheln, damit der die nicht direkt nochmal Rendern muss. Oder aber die Anfrage ist einfach unter dem Andrang irgendwo verloren gegangen…
Naja man wirds nie wissen, aber scheint ja doch alles zu funktionieren
Grüße
Hat jemand Lust meine Vermutung mal auszuprobieren?
Ich habs gerade für den Waldumriss w84598163 ausprobiert und wenn mich mein Browsercache nicht verarscht, denke ich, dass ich damit so einen Effekt in Zoomlevel 18 (in diesem Fall einen “verschwundener” Wald http://www.openstreetmap.org/relation/7522317#map=18/47.63670/12.19770)) erzeugen konnte.
Meine Schritte:
Kontrolle der Kachel http://tile.openstreetmap.org/18/139954/91519.png/status
Tile is clean. Last rendered at Tue Aug 29 20:42:47 2017. Last accessed at Tue Aug 29 20:42:47 2017. Stored in file:///srv/tile.openstreetmap.org/tiles/default/18/33/38/37/183/8.meta
In einem einzelnen Changeset landuse=forest vom Waldumriss entfernt, ein neues MP #7522317 mit type=multipolygon erstellt (aber ohne landuse=forest) und den w84598163 als outer hinzugefügt. Als Changeset #51556581 hochgeladen
Auf die Kachel per http://tile.openstreetmap.org/18/139954/91519.png zugegriffen (STRG+F5 im Browser) => Wald verschwindet (ist ja auch richtig)
Kontrolle der Kachel http://tile.openstreetmap.org/18/139954/91519.png/status
Tile is clean. Last rendered at Tue Aug 29 20:46:24 2017. Last accessed at Tue Aug 29 20:46:24 2017. Stored in file:///srv/tile.openstreetmap.org/tiles/default/18/33/38/37/183/8.meta
In einem weiteren Changeset landuse=forest dem MP #7522317 hinzugefügt und als Changeset #51556657 hochgeladen
Auf die Kachel per http://tile.openstreetmap.org/18/139954/91519.png zugegriffen (STRG+F5 im Browser) => Wald bleibt verschwunden (das ist nicht richtig und sieht für mich so aus, als ob die MP-Änderung nicht um Dirty-Status geführt hat)
Kontrolle der Kachel http://tile.openstreetmap.org/18/139954/91519.png/status
Tile is clean. Last rendered at Tue Aug 29 20:46:24 2017. Last accessed at Tue Aug 29 20:46:58 2017. Stored in file:///srv/tile.openstreetmap.org/tiles/default/18/33/38/37/183/8.meta
Ich hoffe mein Rechner verarscht mich hier nicht…
Hi, ich hatte das Fenster wohl shcon was länger offen und daher eigentlich nur auf deinen ursprünglichen Beitrag geantwortet. Dass du tatsächlich nen Punkt verschoben hattest, hab ich erst jetzt gesehen^^
Zur Sache:
Solche fehler passieren mir eig hin und wieder mal, wenn ich eigenschaften von einem Objekt auf ein anderes übertrage. Das mache ich nämlich noch händlisch via JOSM, indem ich beide Objekte markiere und die Values durch Doppelklick und dann zweimal Pfeiltaste nach unten und dann Enter festlege, da in der Auswahl, die dann ausfährt das häufigste Value an oberster Stelle steht. Einzigste Ausnahme: Das highway-Tag, da ist an erster Stelle ein leeres Feld, was dazu führt, dass der Tag komplett gelöscht wird…
Warum das so ist kann ich beim besten Willen nicht sagen, aber das ist ja zum Glück das Tag, was gerendert wird, was bedeutet, dass man seinen Fehler schnell bemerkt.
Ich will aber auch nicht ausschließen, dass ich das in der Konstellation tatsächlich zum ersten mal hatte. Von mir aus kann ich das nochmal wegnehmen von dem Bahnsteig und dann schauen was passiert.
Grüße
Hi hsimpson,
ja, das wäre nicht uninteressant, wenn Du railway=plattform vom MP nochmal entfernst. Aktuell würde eine der betroffenen Kacheln http://tile.openstreetmap.org/19/271197/175994.png den Status “Tile is clean. Last rendered at Tue Aug 29 19:52:59 2017” anzeigen, wobei der Bahnsteig angzeigt wird.
Es wäre interessant, ob der Bahnsteig wieder verschindet und wenn ja, ob er nach einem erneuten Hinzufügen des railway-Tags wieder kommt.
Den Renderzeitpunkt zwischen den Schritten kannst Du mit http://tile.openstreetmap.org/19/271197/175994.png/status anzeigen lassen (zur Sicherheit immer vorher http://tile.openstreetmap.org/19/271197/175994.png mit STRG+F5 öffnen)
Grüße
Andreas
Done.
So, der Bahnsteig ist noch zu sehen. Was sagt die Auswertung?
Immer noch da
Hi hsimpson,
Interessant und könnte die Vermutung, dass “geometrielose” Änderungen an MP-Relationen keinen Dirty auslösen, bestätigen.
Laut http://www.openstreetmap.org/relation/7518879/history hast Du gegen 22:40 Uhr das railway-Tag von der MP-Relation entfernt. Das Tile http://tile.openstreetmap.org/19/271197/175994.png steht aber nach wie vor auf Clean mit Renderzeit 20:52 Uhr “Tile is clean. Last rendered at Tue Aug 29 19:52:59 2017” und zeigt daher den Bahnsteig an
, obwohl der laut Tagging nicht mehr vorhanden ist.
Kann noch ein anderer Mapper unsere Theorie (siehe #29) mal testen?
Grüße
Andreas Binder
Warum nicht gleich die Leute fragen die sich damit auskennen: pnorman, lonvia, tomhughes und Nakaner natürlich.
osm2pgsql hat eine solche Logik (https://github.com/openstreetmap/osm2pgsql), für die Hauptkarte kommt aber eine eigene Logik zum Einsatz (offenbar ohne Relationen): https://github.com/openstreetmap/chef/blob/master/cookbooks/tile/files/default/ruby/expire.rb
Unbedingt lesen: https://github.com/openstreetmap/osm2pgsql/issues/709
Hi, ich steige an der Stelle aus, da das meinen Horizont derzeit etwas überflügelt
@Andreas, gehst du dem weiter nach?
Viele Grüße
Ich habe mal als ersten Nakaner angeschrieben. Vielleicht weiß er mehr dazu…
