ich habe mir die Stelle https://www.openstreetmap.org/way/224209175 und die Historie angesehen. Wenn nach dem Trennen des Gebäudes vom Flussbett die Darstellung wieder passte, war das eher ein Nebeneffekt (Tile-Kacheln wurden daraufhin dirty und neu erstellt) oder zeitlicher Zufall. Sollte sowas nochmal vorkommen, gibt uns zeitnah Bescheid bevor Du Korrekturversuche machst. Dann haben wir die Chance die Ursache zu finden.
Du kannst gerne das Gebäude wieder verbinden und wenn danach die Welt wieder blau wird, habe ich mich geirrt und es gäbe einen Bug beim Renderer. Aber ich glaube eher die Welt bleibt so, wie sie ist
Die Ursache für das Blau war meiner Meinung nach ein Mapperfehler. Und dabei musst nicht zwingend Du der Mapper gewesen sein. Vielleicht hat ein anderer Mapper zeitgleich einen MP beschädigt und Du hattest das Gefühl Deine letzten Änderungen wären die Ursache.
@wambacher
Das mit “…Micromapping Multipolygone öfters ohne geschlossenen Äußeren Ring…” ist bei Johann so gemeint, dass seine Relationen nicht einen einzelnen Weg als Outer haben, sondern es sind mehrere Linien, die als Linienzug geschlossen sind, d.h. technisch OK, aber sehr fehleranfällig.
Aber es gibt auch Mapper, die nicht jeden Trend mitmachen: Dieses “Wir versuchen es möglichst einfach zu machen und vermeiden daher Multy-Way-Polygone” ist ja recht jung (2-3 Jahre?). Noch schlimmer: “Wir erstellen nur noch Multipolygone, wo es absolut nötig ist” ist ja noch moderner (1-2 Jahre?)
Den “Carto Fehler” hast Du so aber nicht gefixt. Wenn tatsächlich der Renderer an so einem trivialen Fall scheitert, dann sollte das nicht nur an den Daten korrigiert werden.
Ich gehe inzwischen davon aus, dass mit Regelmäßigkeit über ganze Landstriche ausufernde Farben, sowie Carto Performance Probleme im Seitenaufbau speziell getuned sind.
So als ob man Wikipedia Webseiten, nur mit erheblichen Hürden und langsamen Seitenaufbau lesen könnte, kostenpflichtige WP Reader hingegen einen High Performance Zugang anbieten.
Ich habe keine Ahnung wofür man für OSM gespendetes Geld einsetzt, jedenfalls nicht für funktionierende Carto Server und sauberen Carto- Code.
Das ist kein Fix, vielmehr hast Du das Problem in Carto (wenn es denn eines ist) per „Tagging für den Renderer“ verschleiert. Bitte diese Änderung rückgängig machen und den Fehler in Carto mit Hinweis auf die betroffenen Objekte melden. Nur so erzielen wir Fortschritte.
Was möchtest Du uns damit sagen? Ich kann nur raten. Dass die OSM-Daten (oder Carto?) absichtlich so manipuliert werden (von wem?), dass die OSM-Daten von kostenloser Software (also Carto?) nicht richtig dargestellt werden und somit irgendjemand (wer?) damit Geld verdienen kann (wie?)?
Danke für den Hinweis. Mir wurde bereits einmal beschieden dass meine Feststellung “Verursacher einer ausufernden Farbe Gebäude auf einer Grenzfläche eines Gewässers”, falsch sei. Der Aktuelle Fall bestätigt hingegen nun den von mir festgestellten Sachverhalt. Das müsste eigentlich zum Reproduzieren des Problems in der Sandkiste ausreichen.
Die Leser deines Beitrages. Das hätte ich ebenso formuliert. Außerdem eine ironische Anspielung auf „Was wollen uns diese Worte sagen?“.
Mir kommt es ein wenig vor, als wolltest du jetzt künstlich Fronten aufbauen, wo gar keine sind.
Wenn du keine Ahnung von den bei OpenStreetMap Carto verwendeten Renderingtechniken hast, solltest du die Klappe halten und nicht so tun, als hättest du Ahnung.
Der Kartenstil besteht aus mehreren Ebenen, die in einer festgelegten Reihenfolge gezeichnet werden. Das layer=*-Tag hat nur auf die Sortierung der Elemente innerhalb einer Ebene Einfluss und auch nur dann, wenn es in dieser Ebene auch ausgewertet wird. “Darstellungsfehler” bleiben so lange bestehen, bis die Kachel neu gerendert wird. Eine Kachel wird neu gerendert, wenn sie für veraltet erklärt wird. Kacheln werden in Blocks á 8x8 Kacheln auf einmal gerendert, damit Beschriftungstexte auch über die Kachelgrenzen hinausreichen können und weniger Dateien auf der Festplatte herumliegen. Wenn innerhalb eines solchen Metakachel eine Veränderung der Daten erfolgt, die zur Markierung als “veraltet” führt, wird die Metakachel in die Jobliste der neu zu renderenden Kacheln aufgenommen.
Nicht jede Änderung an den OSM-Rohdaten führt dazu, dass eine Metakachel als veraltet markiert wird. Welche Veränderungen zu einer Markierung führen kann dem Expire-Skript, das von den OSMF-Tileservern verwendet wird, sowie der Wiki-Seite Tile expiry methods und den dort verlinkten Quellen entnommen werden. Ich erkläre das jetzt absichtlich nicht, weil das einem Mapper eigentlich egal sein sollte. OSM ist nämlich ein Datenprojekt und kein Kartenkritzelprojekt.
Glaub mir, ich habe Ahnung, ich verdiene damit mein Geld.
Bitte entschuldige dich für das Verzapfen dieses Stusses!
Wir bekommen alle paar Wochen eine Koordinate von der übergeordneten Organisation Struktur zugewiesen und müssen dann schnell ein Bild zurückschicken, in dem dieses Gebiet ohne Überschwemmung gerendert wird. Gestern wars zufällig der Pillersee:
Ein paar Tage später kommen 1 bis 3 BTC (je nach Kurs). Ich lebe inzwischen recht gut davon, keine gute Karte anzubieten und die schlechte mit Mapserver statt Mapnik zu rendern.
uns ist der Dativ von Wir OpenStreetMapper; und weil er bescheiden ist, schreibt er sich klein.
@kreuzschnabel/#30:
Danke! Es ist schon seltsam, dass man sich hier neuerdings für den Gebrauch des Dativs verantworten muss … danke, dass Du die Erklärung übernommen hast!
@maxbe/#32:
Ah, super! Dank Deiner Erklärung haben Wir OpenStreetMapper endlich verstanden, wie der Hase läuft …
Dank Deiner Erklärung haben Wir OpenStreetMapper endlich verstanden, wie der Hase läuft …