hier http://www.openstreetmap.org/relation/1955526 ist ein relativ großes Multipolygon mit landuse=meadow, aus dem fein säuberlich (fast) alle residentials und forests ausgestanzt sind. Jetzt hat ein iD user aus Versehen das MP zum residential gemacht, ich habe es nach Rücksprache wieder auf meadow geändert. Aber jetzt fällt mir auf, dass einige der residentials gerendert werden und andere nicht. Gut zu sehen in der Gegend von Ober- und Unterostendorf: Beide mit residentials welche “inner” des MPs sind.
Könnt ihr den Grund dafür erkennen?
OSMI hatte nur einmal “touching lines” bemängelt, die ich dann auseinandergenommen habe.
Die JOSM-Prüfung meldet 2 Warnungen “Zeichenstil für innere Linie mit Multipolygon identisch” was ich nicht kapiere. Die gefundenen Fehler sind eine landuse=landfill und eine landuse=industrial, beides “inner” des MP.
Ich würde das MP am liebsten in handliche Teile zerlegen, aber erst interessiert mich wo da der Wurm drin ist. Danke!
Und dein Outer ist eine landuse=meadow.
Nach Meinung der JOSM-Prüfung soll dann en Inner nicht ebenfalls landuse sein. Dass dabei zwei verschiedene Werte von Landuse verwendet werden, ist wohl ohne Bedeutung für die Meldung.
Im Prinzip kannst du diese Meldung bei unterschiedlichen Werten ignorieren. Wie die Renderer damit umgehen, ist jedoch eine andere Frage.
Bei mir tritt die Meldung in JOSM nicht auf. Dass das inner eines landuse-MP wieder ein landuse ist, ist aber eigentlich normal und
produziert normalerweise keine JOSM Fehlermeldung.
Zu dem unterschiedlichen Rendern: einfach Warten bis alles wieder aktualisiert.
Ich hab JOSM tested, Version 6388, du benutzt die 6238, oder? Der farmyard den du angelegt hast, wird bei mir jetzt auch angekreidet…
Es scheint also eine neu hinzugekommene Meldung zu sein. Ich finde auch, dass landuse in landuse recht häufig vorkommt und deshalb keine Meldung produzieren sollte.
Außerdem sind ja auch noch weitere landuses als inner dabei, und die werden nicht angemeckert.
Das ist bei den meisten Zoomstufen schon neu gerendert worden, da muss noch was anderes dahinter stecken.
Ja, würde ich auch. Aber hier ist das vielleicht ein Hinweis darauf, das noch was nicht stimmt.
Warum wird z.B. das landuse=residential innerhalb des MPs nirgends bemängelt? Warum wird mal ein inneres residential gerendert, und mal nicht? Warum zeigt OSMI gar keinen Way für Westendorf an, obwohl da kein Unterschied zu den anderen zu erkennen ist?
Mysteriös
Naja, Wiese und Industrie sind schon unterschiedliche Farben. Außerdem, woher will JOSM wissen, wie irgend ein Renderer das anmalt?
Farmland ist vielleicht besser, ja. Aber wenn ich da was mit mache, dann zerlege ich es in kleinere Teile. Die dann meistens keine MPs sein müssen.
ich habe mal den Umriss von Unterostendorf nach Bing genauer gezeichnet - nun stimmt auch die Farbe.
Scheinbar braucht der Renderer einen Anstoß (veränderte Daten des Umrisses), um diese Fläche neu zu zeichnen - ein /dirty an die Kachel gehängt reicht da nicht.
Sobald auch nur ein einziger Node in einem Way ganz leicht verschoben wird (oder ein neuer hinzugefügt wird), legt mWn die Toolchain los.
osm2pgsql, das ja die OSM-Daten in die Datenbank überträgt, “merkt”: aha Node geändert! → alle Ways neu berechnen, die diesen Node beinhalten und danach alle Rels neu berechnen, die diese Ways als Member haben. Das kaskadiert richtig heftig.
So werden schon mal aus einem verschobenen Node in der Grenze von Deutschland 3-5 Ways und daraus 5-10 Relationen, die alle neu berechnetet werden müssen. (und das sind dann nicht gerade die kleinsten)
Ich nenne das auch “kitzeln”. Damit hab ich ähnliche Probleme mehrfach hinbekommen.
Das ist keine Lösung. Jetzt ist da ein schmaler, in der Realität nicht existierender Meadow-Streifen entstanden. Man kann die Fehlermeldung ignorieren oder eine neue Linie um das Ganze ziehen.
Die Fehlermeldung tritt nach meiner Erinnerung dann auf, wenn sich zwei Gebiete nur in einem Punkt berühren, egal ob in einem Zug (als Achter) oder als (Fast-)Exklave gemappt. Zieht man den Berührungspunkt nur um Zentimeter auseinander, ist Ruhe. Das widerstrebt mir aber und ich ignoriere lieber die Fehlermeldung an diesem Punkt.
Nur zur Info, user sulagaloh hat sich der Sache angenommen, und räumt ein wenig auf. Ich werde ihm auch helfen, soweit ich Zeit habe.
Das ist sehr interessant, danke!
Trotzdem wundert mich, wenn beim neuzeichnen der Kachel nur die “outer”-Fläche neu gefärbt wurde, und die angrenzende “inner” residential nicht überprüft wurde. Es wird doch eine neue Kachel erstellt, da muss doch z.B. ein vorhandenes building auch neu gerendert werden und deswegen die Daten angeschaut werden? Oder wird auf die alte Kachel draufgemalt??
das stark vereinfacht werden sollte… (Stand: 16.12.2013, 21:06Uhr)
Relation http://www.openstreetmap.org/relation/1955526 ist invalid. = Fehlerhaft: Outer ist nicht geschlossen… Im Zweifelsfall merkt man es daran, wenn man bei JOSM im Relationseditor die Elemente sortieren will und sich in der Anzeige des Editors die graphische Anzeige des Outers sich nicht schließt. Also: Ring ist nicht geschlossen!!! Der Renderer weiß anscheinend nicht mehr nach was er die Fläche rendern soll…
Meiner Ansicht passiert das, wenn zu große, aus einzelnen Liniensegmenten zusammengesetzte MP-Relationen durch zuviele neu hinzugefügte Elemente verschiedenster Nutzer nicht mehr händelbar sind.
Mein Tip: MP stark vereinfachen: Wenn, dann Relationen mit jeweils einem geschlossenen Outer und möglichst wenigen inner-Rollen. Dann klappt das auch mit dem Nachbarn… äh… dem Rendering.
Nachtrag: es zeigt sich schon im Link recht deutlich, wo mindestens geteilt werden sollte.
An dem Zusammentreffen im Norden Norden der beiden Teilflächen ist die Linie unterbrochen. Die östliche und die westliche Hälfte müssen getrennt (oder die Linie dazwischen aus der Relation entfernt) werden. Ein einfaches Verbinden am o.g. Punkt würde wieder eine invalide Geometrie hervorrufen.
analysiert Sven weiter… der da keine Hand anlegen möchte, weil er nicht weiß, vie viele da jetzt zu Gange sind.
Hallo Sven,
der momentane Zustand ist ein work-in-progress, weil sulagaloh angefangen hat, das MP in brauchbare Flächen zu zerlegen. Vorher war es bis auf die 2 JOSM Meldungen und die “touching lines” vom OSMI anscheinend in Ordnung. Ich werde das MP jetzt genauso teilen wie du es vorschlägst. Vielleicht lösche ich es aber auch ganz.
Ganz einfach: bei Potlatch 2 bekommt man dann nicht nur die Relation “Multipolygon” mit ID “1955527” angezeigt, sondern “Multipolygon Felder”. Wenn man mit Shift-R eine Liste von Relationen übernommen hat, lassen sich die nicht passenden MP sehr leicht erkennen und rauslöschen. Oder ein übernommener MP mit Funktion “outer” erkennen und auf “inner” setzen.
Kurz: ein “ref”-Tag erleichtert das Mappen mit MP ungemein, führt aber nicht wie der “name”-Tag dazu, dass überall Textlabel in der Karte erscheinen.
Falsche ref=* sind aber auch nicht besser als falsche name=. Wie wäre es mit note= oder (besser) Editor verbessern (JOSM zeigt das anhand der normalen Tags an)?
