Nein, bitte nicht, das ist keine Lösung sondern ein Workaround - Tagging für den Renderer. Wenn Carto ein (weltweites!) Problem hat, dann öffne bitte ein Ticket (oder denke darüber nach, ob das Gebäude wirklich nahtlos an den See grenzt/grenzen muss)!
P.S. Nationalstolz ist schon gut, aber hat hier nichts zu suchen (ist sowieso das Austria Forum). “Wir Österreicher” können vor allem individuell für uns selbst sprechen.
Es handelte sich eher um einen temporären Fehler, auch in Deutschland und anderen Teilen Österreichs wurden manchen Stellen als Gewässer gerendert. mittlerweile hat sich das aber wieder normalisiert. Zumindest wenn ich auf die Karte schaue.
Das Blaue Thema verfolge ich nun bereits Monaten. Immer das Selbe, es wird bagatelisiert und mit Zynismus geantwortet
Inzwischen bin ich soweit:
Ausuferndes Blau ist genauso wie größere Zoom Stufen mit sich extrem langsam verflüchtigendem Grau Kacheln, kein Fehler sondern ein gewolltes Feature. OSM Carto wird so für den Konsumenten unbrauchbar.
Leute sollen bei gewissen Firmen aufbereitete OSM MAP Tiles kaufen, Bezahl WMS Services bleiben von von Blau und Grau in wundersamer Weise verschont.
Witz komm heraus, selbst mitten in London finden sich in gewissen Zoom Stufen Stadtteile in Blau,
das Thema wurde auch schon im Deutschen OSMForum erörtert. Und ich Johann aus Tirol soll das nun melden.
Klartext, dieses Verhalten haben jene Leute welche aktuell am OSM Code herumschrauben zu verantworten, die Problematik ist zu lange allseits bekannt.
Meine Frage war nicht zynisch und ich habe auch nicht bagatellisiert, es ist ein uraltes Problem. Ich habe jetzt das layer Tag wieder entfernt, schau ma mal, ob die Blaeue wieder kommt.
Man weiss, wen Kuestenlinien kaputt sind, kann sich alles blau faerben. Ich dachte aber, dass die Kuestenlinien irgendwie gesondert behandelt oder ueberwacht werden.
Nachdem der Renderer dort neu rendert, wo man etwas veraendert hat, ist es aber nicht unlogisch, dass dort immer zuerst die Blaufaerbung eintritt. Oder irre ich hier? Wenn dem so ist, kommt es vielleicht zur irrtuemlichen Annahme, dass man mit dem eigenen Edit den Fehler verursacht hat.
[Edit: Schiache Grammatik in weniger schiache Grammatik]
Wenn Gewässer auf carto-osm “auslaufen” ist dafür mW eine Lücke in der Uferlinie erforderlich, das kann beim Mappen schon mal versehentlich passieren, z.B. wenn das Ufer durch Multipolygon-Segmente zusammengestückelt wird, wie hier https://www.openstreetmap.org/way/565944937
Versuche bitte sachlich zu bleiben, wir sind kein Forum für Verschwörungstheorien
die von Dir angesprochene Waldfläche hat natürlich keine Lücke.
Du hast mich aber auf einen anderen Umstand hingewiesen, Danke.
Wie die Erfahrung bei Multipolygon Strukturen zeigt, neigen unrunde MP Formen zu Rendering Problemen.
Der Wald stammt natürlich hier nicht von mir, sondern aus einem sehr alten Wald Import https://www.openstreetmap.org/changeset/472616
Ich löse unrunde MP Strukturen -wo ich solche antreffe- in annähernd Runde MP Strukturen auf.
Warum der Renderer bei unrunden Strukturen aus den tritt kommt ist einfach erklärt. Es handelt sich hier um ein sehr altes grundsätzliches Designe Problem von OpenStreetMap. Es fehlt Linien welche Teil einer Fläche sind eine klare innen / aussen Information. Der Renderer muss daher zur Interpretation der Fläche erst das gesamte Polygon Konstrukt laden.
Uns Mappern wird immer wieder vorgeworfen wir sollten nicht für den renderer Mappen. Die Wahrheit ist hingegen, hier haben die Entwickler von OSM
gepfuscht.
Deren Fix lautet, einen geschlossenen äußeren Rind zu verwenden.
Oder wie immer wieder gepredigt MP Strukturen überhaupt zu vermeiden.
Liebe OSM Entwickler, meiner Meinung nach seid Ihr hier am Zug. Gängelt bitte nicht uns Mapper.
Mittels umdrehen der Sortier Reihenfolge sollte noch die Kreisform verbessert werden. (aktuell noch nicht erledigt)
Also Zwei Versuche: 1. Polygone in Reohe bringen, 2. durch abtrennen ein zweites Wald Polygon erzeugen, und so zwei annähernd Runde MP Strukturen erzeugen.
Das kann auch noch altes Material sein, es wird ja nicht jede Zoomstufe gleich schnell gerendert
In letzter Zeit habe ich mit dem Rendering von MPs eigentlich nie Probleme. Ich haenge also derzeit kein Anhaenger Deiner Theorie mit den runden Formen von MPs.
Mein Hauptverdacht: Es sind Ferneffekte, die sich durch lokales Editieren eigentlich nur deshalb bemerkbar machen, weil der Renderer neu editierte Zonen neu rendert und dort die Ferneffekte zeitnah sichtbar werden.
Verursacher ausgelaufener Farbe Blau identifiziere ich, indem ich in Schritten näher heran zoome. Je Größer die Zoom Stufe, desto kleiner wird der Radius in Blau um den Verursacher. Bislang war der Verursacher immer ein an ein Gewässer angedocktes Gebäude. Die Gewässer Polygon Form (MP oder Einzelpolygon) hat hingegen keinen Einfluss.
Meine neue These dass in der nähe befindliche andere komplexe Polygon Formen zur Interaktion neigen.
Naja, dann schauen wir mal, wie sich die Sache in dem Bereich dort weiter entwickelt. Sollte die blaue Farbe weg gehen, dann war es ein “Ferneffekt” sollte in den naechsten 24h-48h wieder alles blau werden, dann war es die Huette am Fischteich!
Es treten - aufgrund von Edit-Fehlern, nicht aufgrund von “unrunden” Flächen - schon mal “Überflutungen” auf, die aber relativ schnell in den Daten beseitigt werden.
Es dauert aber einige Zeit, bis die neuen “sauberen” Tiles gerendert werden und auch wirklich beim Anwender ankommen. Das Re-Rendern erfolgt für unterschiedliche Zoomstufen in unterschiedlichen Zeitabständen (von quasi realtime bis zu Stunden) und dazu kommt das Caching des lokalen Browsers.
Nicht alles, was der Anwender sieht, entspricht den aktuellen Tiles und erst recht nicht dem aktuellen Datenstand.
Dass da manche Anwender den Überblick verlieren und zu wildesten Spekulationen neigen, nehme ich hier mal belustigt zur Kenntniss.
Gruss
walter
todo
1: echten Fehler beseitigen
2: etwas warten
3: Cache löschen
4. Reload Browser.