Es müsste unbedingt mit iD etwas passieren. Ich habe auch schon einiges “verschobenes” gerichtet. Solche “Fehler” schrecken dann einen “Neuling” ab, weiter zu machen.
Ist das auch eine Wunderlichkeit von iD, oder ein ganz normaler Unfall, der nur jetzt besonders auffällt?
Mein Renderer wurde heute von der Relation 3210476 ermordet. Irgendwie kommt die DB und Renderer nicht gut damit zurecht, dass da ein Weg zweimal als outer in einem Multipolygon ist. Die Relation sieht so aus, als sei sie aus einem ihrer Mitglieder entstanden (die rechte Hälfte des Golfplatzes) und hätte dessen Tags geerbt…
war ja auch totaler quatsch. ein outer und dadrin nochmals zwei Teilflächen als outer.
die Linie, die da quer durchging, hatte keinerlei Funktion. Da ist nix, was eine Teilung in Ostteil und Westteil gerchtfertigt hätte.
Sorry, ich hab die rel platt gemacht ohne dran zu denken, dass dann auch die History weg ist - ist wohl heute nicht mein Tag:(
Unabhängig von den iD-induzierten Defekten ist das für mich ein Mangel des Renderers. Alles, was mit OSM-Daten arbeietet, muß in hohem Maße fehlertolerant sein, und unverständliche, falsche oder schon auf niedrigster Ebene kaputte Daten schlicht ignorieren oder auf den korrekten Anteil reduzieren. Für Multipolygone, die man auch ohne iD mühelos kaputt bekommt, gilt das erst recht.
Jo. Der Renderer wurde ja auch heute um eine Zeile toleranter Manche Fehler muss man halt erst mal gesehen haben, um sie wegputzen zu können… Um die mir bisher bekannten Geometriefehler hat sich osm2pgsql bisher ganz gut gekümmert oder zumindest was ausgespuckt, was der Mapserver verdauen oder ignorieren konnte.
Da habe ich auch was: http://www.openstreetmap.org/browse/relation/1982737/history
Neben der inzwischen leidvoll gewohnten Umwidmung großer Gebiete finde ich besonders verstörend, daß hier eine Selbstreferenz in die Relation eingebaut wurde (siehe “Relation 1982737” in der Mitgliederliste von Version 2 und 3). Mir ist keine Situation bekannt, in der so etwas Sinn macht - bei einem Multipolygon aber ganz sicher nicht.
Naja, wenigsten hatte WALL-E die abgekürzte Seifentalstr. korrigiert
Konntest du die Adresse retten, also das Restaurant finden? Ansonsten schlägt der Mapper bald wieder zu. Laut Changeset wohl nicht.
Ja, blöd sowas. Aber eine vorherige Prüfung der Objekthistorie, ob das Restaurant vielleicht vorher mal ein Wald war, scheint mir auch zu aufwendig. Das ist eher eine Aufgabe für ein separates Werkzeug. Immerhin habe ich so überhaupt den Fehler gefunden.
Nein, kein Hinweis darauf. Entweder merkt der User irgendwann, daß “sein” Restaurant in “der Karte” immer noch fehlt, und trägt es erneut ein, dann hoffentlich etwas kleiner. Oder (wahrscheinlicher) es bleibt bei dem einen Änderungssatz. Habe gerade mal eine Note hinterlassen, vielleicht kommt ja mal jemand von den regionalen Mappern in der Nähe vorbei.
PS. Die Google-Karte auf der verlinkten Website (sofern die dort skizzierte Position überhaupt stimmt) unterliegt natürlich einem “Beweisverwertungsverbot”.
Ich habe einen Fall, bei dem der Nutzer selbst das danach gelöscht hatte. Der Nutzer ist bereits informiert, könnte das jemand reverten (also die Nodes von Way 49736341 und den Way selbst auf die letzte Version von Schusch)?
Ich weiß nicht, ob das hier schon erwähnt wurde, aber die hier erwähnten Probleme werden hauptsächlich durch den Bug #1693 von iD verursacht, der auch bereits seit Längerem gefixt wäre. Leider hat der Patch es noch nicht in ein Release geschafft. Außerdem ist ist John Firebaugh z.Z. im Urlaub, deshalb könnte es noch etwas dauern bis es auch auf osm.org gefixt ist.
landuse=residential
Da es beide Male der Selbe war und er schon ein Weilchen dabei ist: Hast du ihn schon darauf aufmerksam gemacht? Falls nicht würde ich das machen.