Mapnik Probleme?

Ein Kapelle, die von mir irgendwann als christlich markiert wurde, hat vier Wochen – oder mehr – gebraucht, um mit einem Kreuz dargestellt zu werden. Ich habe nichts weiter gemacht. Einfach nur gewartet. Irgendwann werden wohl alle Kacheln mal neu gerendert.

PS: Es wird nicht für einen speziellen Renderer gemappt! Wenn’s mit Osmarender oder sonst einem funktioniert, scheint ja alles in Ordnung zu sein.

Wann was in “Mapnik” neu gerendert wird, ist etwas kompliziert. Es kann also alles zwischen innerhalb von 5 Minuten bis hin zu Wochen, theoretisch auch Jahren sein bis etwas aktuallisiert wird. Letzteres allerdings nur wenn nie jemand die Karte in der Zwischenzeit sich anschaut.

Normalerweise sollten die “Mapnik” Karte aber sehr aktuell sein, wobei zur Zeit der Server etwas ueberlastet ist, sodass es nun haeufiger etwas aelter ist.

Bei groesseren Waldgebieten, oder bei Multi-polygon relations, kann es aber auch sein, das der automatische Mechanismus nicht funktionier und man der Karte manuell sagen muss, das sich das Gebiet geaendert hat und es desshalb neu berechnet werden muss.

Eine ausfuehrlichere Erklaerung wie das ganze funktioniert findet man (auf Englisch) unter http://help.openstreetmap.org/questions/178/how-often-does-the-main-mapnik-map-get-updated

Wenn etwas nur anders getaggt wurde, löst das m.W. kein Rendern aus.

Baßtölpel

Kann gut sein, sonst müsste wohl zu häufig alles neu gerendert werden. Meistens ist’s ja auch egal, ob das etwas länger dauert. Man wundert sich höchstens, ob man jetzt was falsch gemacht hat, weil man nicht gleich das Ergebnis sieht.

Fuer Ways und Nodes sollte es eigentlich schon. Eine Zeit lang (c.a. ein Jahr weil es keiner gemeldet hatte) war ein Bug im Wege code, sodas Way aenderungen nicht korrekt registriert wurden, aber das ist inzwischen auch schon wieder eine weile her das das gefixt wurde.
Relations hingegen werden im expiry code nicht beruecksichtigt. Auch werden die Flaechen inerhalb von grossen Polygonen nicht beruecksichtigt, sondern nur die Umrandung.

Es scheint mir eher als ob falsch gerendert wird als gar nicht gerendert.

War anscheinend doch ein mapping Problem: eines der “Löcher” im Wald war mit “innter” statt “inner” gekennzeichnet.
Nach der Korrektur ist der Wald jetzt (noch teilweise) da.

Ich hänge mich hier mal hinten dran.

Ich habe hier eine Stelle in der Stadt, die auf einigen Karten (z.B. TAH) korrekt und auf anderen (z.B. Mapnik) nicht korrekt gerendert wird.

Es exisitert bereits ein Fehlereintrag bei OSB.

Vielleicht findet jemand von euch die Ursache.

http://openstreetbugs.schokokeks.org/?zoom=18&lat=52.13024&lon=11.61365&layers=B00T

Danke+Grüße

Lösche die 3-4 buildings und trage sie neu ein. Das hilft in 99% aller solcher Probleme.

siehe auch hier: http://forum.openstreetmap.org/viewtopic.php?pid=207675#p207675

Gruss
Walter
lass dich von dem Bild nicht zu sehr verwirren. Es ist eben so, dass es sogar DREI Datenbanken gibt ( OSM-, Mapnik- und TAH-Daten) die theoretisch abweichende Inhalte haben können.

Danke! Ich versuche das mal.

Wäre natürlich schön, wenn man die Ursache hätte eingrenzen könnte.

Ich stehe ja schon mit meinen Kommentaren in dem erwähnten OSB-Bug, aber da der nach dem Schließen nun bald verschwunden sein wird, will ich es hier auch noch mal erwähnen: Ich hatte (übrigens nur ein paar Straßen weiter) auch schon mal dieses Problem, das ich dann (leider erfolglos) unter http://trac.openstreetmap.org/ticket/3549 gemeldet habe. Damals reichte es auch schon, das nicht gezeichnete Objekt in irgendeiner Form zu verändern, sodass es neu auf den Server hochgeladen wurde. Am wenigsten invasiv erschien mir das Einfügen und gleich darauf folgende Löschen eines Knotens in der Fläche mit JOSM, noch vor dem Hochladen. Effektiv war das Objekt also identisch zu dem vorigen, es hatte nur seinen Versionszähler erhöht. Auch nicht schön, aber IMHO deutlich besser als das Kopieren und Löschen des alten Objekts, wo dann die Chronik verloren geht.

Ich kann mich hadhuey nur anschließen: Es wäre schön, wenn man irgendwie das Problem eingrenzen und eliminieren könnte. Es tritt ja offenbar immer wieder mal auf. Ich meine mich erinnern, dass die nicht gezeichneten Gebäude in dem von hadhuey geschilderten Fall so wie in meinem Fall auch fälschlich mit der inner-Rolle in einer multipolygon-Relation steckten. Ich habe diese Gebäude zumindest in meinem Fall aus dieser Relation entfernt, ohne die Gebäude selbst irgendwie zu verändern. Hilft das irgendwie weiter, das Problem einzugrenzen? Das Diagramm aus dem von wambacher verlinkten Thread ist ja interessant, aber ich kann lediglich erkennen, dass das Problem wohl irgendwo in dem gelben Bereich steckt. :slight_smile: In dem dortigen Thread spielen die multipolygone ja offenbar auch eine Rolle.

Wenn man wüsste, welche Komponente die richtige ist, könnte ich ja ggf. auch meinen Bug in Trac wieder eröffnen und der richtigen Komponente zuordnen. Kann da jemand helfen?

Meine Erfahrung ist, dass wenn ein Inner-Element real kein Inner sondern ein Outer ist (quasi eine weitere disjunkte Fläche) dann ignoriert Mapnik die Taggs am (falschen) ‘Inner’-way und verwendet stattdessen die Taggs des Multipolygons. Das Entfernen der falschen Inner-Elemente aus der Multiplygon-Relation hilft dann die Dinge wieder gerade zu rücken.

Im Grunde halte ich dieses Verhalten von Mapnik für richtig oder zumindest angemessen. Mapnik kann nicht entscheiden, ob nur die Rolle falsch gesetzt ist, oder ob das Outer der Multipolygon-Relation so geändert wurde, das ein Inner nicht mehr innen liegt. Aber es ist halt schwer für die Mapper, diesen Fehler zu erkennen.

Du kannst ja mal dein Ticket um diese Information (Inner wird unbeabsichtigt zum Outer) ergänzen.
Ob man das Verhalten von Mapnik in so einem Fall ändern sollte oder nicht, ist eine andere Frage.

@Frederik: Findet der Multipolygon-View des OSM-Inspektors solche falschen Inner-Elemente?

Edbert (EvanE)

Das muss wohl so sein, da die Daten von Mapnik fehlerhaft und die von TAH korrekt waren.
Immer wenn etwas in der OSM-DB geändert wird, wird ca 1 Minute später ein Diff-File mit den Änderungen erzeugt und an die anderen DBs weitergeleitet. Dadurch werden die Daten der Kopien aktuell gehalten.
Geht hier wegen eine Störung mal ein Diff “verschütt”, haben wird den Salat. (*)
Daher sind die beiden Methoden a) Objekte anfassen und verändern b) Objekte löschen und neu eintragen hier hilfreich, da sofort danach die neuen Daten verteilt werden. Hierbei ist das Löschen/Neueintragen brutaler aber sicherer.

Mit irgendwelchen MP hat das definitiv nichts zu tun.

Gruss
Walter

*) Die letzte mir bekannte Störung gab es im Herbst als ca 1/2 Tag nicht gerendert wurde, da keine Diff-Daten mehr bei der Mapnik-DB ankamen.

Ich habe den Eindruck, dass hier ein Missverständnis vorliegt. Die hier erwähnten Probleme ergaben sich ja erst nach der Korrektur der fehlerhaften Relationen. Dass es mit einer fehlerhaften Multipolygon-Relation ggf. zu einer undefinierten/unerwünschten Darstellung kommt, ist ja kaum verwunderlich. Vor meinen Korrekturen war die Darstellung in Mapnik aber sogar (zufällig) korrekt. Da Relationen und die fälschlich darin enthaltenen inner-Wege eh die gleichen Eigenschaften hatten, kann ich aus diesen Fällen deine Erfahrung jedoch weder bestätigen noch in Frage stellen.

Ich habe zwar keine Ahnung, wie es intern abläuft, aber ich finde es recht auffällig, dass das Problem hier und dem anderen Thread in insgesamt drei Fällen aufgetreten ist, wo es um reparierte inner-Rollen in Multipolygonen geht. Zudem ist es mir sonst auch noch nie vorgekommen, dass Änderungen auch nach Wochen noch nicht von Mapnik übernommen wurden. Möglicherweise gibt es ja noch neben den verloren gehenden Diffs noch einen weiteren speziellen Grund im Fall solcher Reparaturen an Relationen?

Mir kommt da so spontan die Idee, dass die inner-Wege möglicherweise in den Daten für Mapnik nicht separat vorliegen, da sie im dortigen Datenbestand Teil eines Multipolygons-Objekts(?) sind. Wenn nun nur ein Diff übertragen wird, werden in den hier vorliegenden Fällen nur die Daten der multipolygon-Relation übertragen, sodass Mapnik von dem Polygon die korrigierte Form erfährt. Der nun eigenständige ehemalige inner-Weg als solcher wurde jedoch nicht verändert und ist folglich auch nicht Bestandteil der Änderung über das API und folglich wohl auch nicht des Diffs. Mapnik wird ihn folglich nie rendern, da er dort ganz einfach nicht im Datenbestand vorliegt. Das ist natürlich mangels Kenntnissen über die Datenformate abseits des OSM-XML-Formats und deren Konvertierung nur eine wilde Spekulation, aber sie würde meine Beobachtung gut erklären können.

Gibt es eigentlich ein ausreichend vollständiges Testsystem, auf dem man meine Theorie ausprobieren könnte? In den normalen OSM-Daten würde ich nicht so gerne solch eine fehlerhafte Relation einfügen. Falls nicht, würde ich bei meinem nächsten Multipolygon doch einfach mal einen zusätzlichen inner-Weg hinzufügen und diesen gleich danach wieder aus der Relation entfernen. So groß dürfte der Schaden dann ja nicht sein.

Zu den offenbar verloren gehenden Diffs: Gibt es dort irgendeine Transaktionssicherheit? Werden die fehlerhaften Transaktionen erkannt und später nachgeholt? Wenn nicht: Wie bekommt man die Daten überhaupt jemals wieder synchron? Gibt es da zusätzlich (regelmäßige) Abgleiche? Die erwähnte Render-Pause von einem halben Tag ist ja die eine Sache, aber was ist mit den Änderungen aus der Zeit? Es wäre zum einen Schade um die nie in Mapnik auftauchenden Änderungen, zum anderen halte ich es für bedenklich, später weitere Diffs auf einen dann unerwarteten Datenbestand anzuwenden. Da könnten sich ja noch üblere, schwer zu lokalisierende Fehler ergeben.

Transaktionssicherheit gibt es hier nicht. Es handelt sich nicht um eine DB-zu-DB-Replikation, die so etwas gewährleisten könnte. Das ist alles “handgestrickt”, läuft aber verblüffend stabil.
ca 1x im Jahr wird das Zeug neu aufgesetzt (Full-Import) Ich erwarte die nächste Aktion mit dem “Big-Bang” in April - vorher macht es eh keinen Sinn mehr.

Gruss
Walter

p.s. ich bin kein Insider. Alle meine Aussagen beruhen auf - durch lange Erfahrung beeinflusste- Vermutungen :wink:

Eigentlich geht fast nie etwas verloren. Wenn mal was ins Stocken kommt, werden die Updates spaeter nachgeholt. Dafuer sorgt das Osmosis, das auch fuer das Updaten der Tileserver-Datenbank eingesetzt wird.

Man muss unterscheiden zwischen “ein Datenupdate geht verloren” (sehr selten, sehr unwahrscheinlich) und “ein Tile wird nicht neu gerendert, obwohl es sollte” (kann durchaus mal vorkommen).

Weil es hier im Thread noch nicht erwaehnt wurde (oder hab ichs uebersehen?) - bevor man munter Objekte loescht und wieder hinzufuegt in der Hoffnung auf ein Neu-Rendering (bitte nicht machen!), erstmal pruefen, wann Mapnik das betr. Tile ueberhaupt zuletzt gerendert hat

http://tile.openstreetmap.org/z/x/y.png/status

und wenn da dann steht “tile is clean, last rendered vor drei Tagen” und man hat aber gestern was geaendert →

http://tile.openstreetmap.org/z/x/y.png/dirty

Das hilft natuerlich nur, wenn Mapnik die Daten in der Datenbank hat, aber aus irgendeinem Grund kein Neurendern noetig fand. Aber in meiner Erfahrung ist das eigentlich meistens die Stelle, an der’s haengt.

Bye
Frederik

Hallo Frederik

Das geht oft genug auch über den Weg

  • Kachel einzeln ansehen (Rechtsklick und im Menü Grafik anzeigen lassen)
  • Die Grafik per Shift-Reload (bei Firefox) neu vom Server holen.
    Dann ist meist in wenigen Sekunden (uns geht es wirklich gut ! ) die neu gerenderte Kachel da.

Mein Eindruck ist, dass Änderungen in der Geometrie (Objekt verschieben / neue Objekte anlegen / …) in der Regel von Mapnik erkannt werden und zum Neu-Rendern der Kachel führt.
Werden hingegen nur Taggs geändert, scheint Mapnik eventuell keine Notwendigkeit zu sehen, die Kachel neu zu rendern. Das ist ja in der Tat bei etlichen Tagg-Änderungen auch nicht notwendig, da sie sich gegebenenfalls auf das erzeugte Kartenbild gar nicht auswirken (smoothness, surface, addr:street, phone …).

Wenn Mapnik allerdings Neurendern für nicht notwendig hält (warum auch immer), hilft nur Anstoßen per angehängtem “/dirty”.

PS: Nur Vermutungen, nicht durch gezielte Tests bestätigt.

Edbert (EvanE)

Ich habe zwei Fälle gehabt, bei denen landuse nicht richtig gezeichnet wurde. Und da heben alle Tricks (ändern des Landuse - Änderung kontrollieren - zurückändern - kontrollieren, als dirty markieren) nichts geholgfen. Die Tiles wurden neu gerendert (ich habe extra Kontolländerungen in direkter Nachbarschaft gemacht). Aber bestimmte Informationen wurden von Mapnik hartnäckig ignoriert.

Eine Beobachtung: In beiden Fällen handelte es sich um Multipolygone und die inner wurden nicht korrekt gezeichnet (hatten eigenen Landuse, wurden aber nicht gezeichnet).

Folgende Operationen lösten das Problem nicht:

  • Änderungen an den MP-Relations Tags.
  • Änderungen an den inner Tags.
  • Löschen und neu erstellen der MP-Relation.
  • Das Löschen des MP (+ Aufteilen des umgebeben Gebiets. + Tags von MP an früheren outer), so dass nur noch "normale Flächen OHNE Überdeckung(!) vorhanden waren.

Nur das löschen und neu erstellen von inner, outer und MP führte zum Erfolg. (nur MP ist zu wenig, aber eventuell muss man outer nicht löschen - nicht getestet)

Gibt es einen Mechanosmus, der Eigenschaften von MP-Realtionen auf Wege konsolidiert und nur diese Wege in der Mapnik-DB speichert? Funktioniert eventuell der Update Mechanismus nicht in allen Fällen, wenn an einem MP oder an einem der inner betimmte Änderungen vorgenommen werden?

mdk

Hier im Thread nicht, aber in dem OSB-Eintrag wurde erwähnt, dass Mapnik die Kachel für aktuell hielt:

Ich bin mir auch ziemlich sicher, dass zumindest in meinem Fall selbst eine manuelle dirty-Markierung der Kachel nicht geholfen hat. Leider habe ich vergessen, das damals zu dokumentieren. Zumindest aber weiß ich sicher, dass die Kachel nach meiner Änderung neu gerendert wurde. Denn gut drei Stunden nach meiner Änderung an dem Polygon habe ich auch den Weg westlich der Kirche mit den Pollern ergänzt - http://www.openstreetmap.org/browse/changeset/7318013. Der ist in dem Mapnik-Screenshot http://trac.openstreetmap.org/attachment/ticket/3549/rendering_mapnik.png zu sehen, während die betroffenen Gebäude aus dem Changeset zuvor fehlen - http://www.openstreetmap.org/browse/changeset/7316028.

Meine Erinnerung, der von mir gefundene Workaround und die Tatsache, dass der neue Weg durchaus gerendert wurde, würde zusammen klar gegen ein lediglich ausgebliebenes Rendern sprechen, während sich das gut mit der von mdk geschilderten Beobachtung aus dem vorigen Beitrag decken würde. Wobei ich eben als anderen Workaround das Verändern des inner-Wegs durch Hinzufügen und Entfernen eines Knotens gefunden hatte. Alle gefundenen Workarounds haben offenbar eins gemeinsam: In einem solchen Changeset würde der inner-Way mit seinen Knoten-IDs immer enthalten sein. Bei den nicht hilfreichen Aktionen jedoch nie. Oder habe ich etwas übersehen?

Interessant finde ich insbesondere, dass bei mdk das Phänomen auftrat, dass der inner-Weg selbst dann nicht gerendert wurde, als die multipolygon-Relation entfernt wurde. Das würde für meine Theorie sprechen, dass weil dieser Weg in dem Changeset nicht auftaucht, er auch nicht an Mapnik weitergereicht wird, dort aber nötig wäre, weil er in dem dortigen Datenmodell bisher nicht separat existiert und man aus dem mutmaßlichen “vorkompilierten” Polygon-Objekt die einzelnen Wege nicht zurückgewinnen kann (oder dies zumindest bislang nicht erfolgt).

Nachtrag noch zu meinem Posting:

Folgende Operationen lösten das Problem nicht:
[…]

  • Kachel mit “/dirty” neu rendern lassen

Da aber dummy Änderungen auf der selben Kachel bereits gezeigt hatten, dass zwar neu gerendert wird, aber trotzdem fehlerhaft, hatte ich es nicht erwähnt. Aber mit “dirty” neu rendern ist bei mir immer der erste Versuch, wenn Mapnik etwas nicht wie erwartet darstellt.

mdk