an die Reparatur Spezialisten ... Wald verschwunden

Hi,

dass was man halt immer macht:
Im JOSM Gebiet runterladen und auf Validator gehen:
1) Fehler
<der interessiert momentan nicht>

2) Warning
Multipolygon: outer fehlt
hier wohl Weg 111601728 + 111601750

=> in die History der Relation schauen, wer den outer entfernt hat
=> den Kollega anfunken: "Was geht ab?"

auf Antwort warten und gemeinsam reparieren

Keine Antwort erhalten => selbst flicken

🙂

Ciao,
Frank

kellerma wrote:

Hi,

dass was man halt immer macht:
Im JOSM Gebiet runterladen und auf Validator gehen:
1) Fehler
<der interessiert momentan nicht>

2) Warning
Multipolygon: outer fehlt
hier wohl Weg 111601728 + 111601750

=> in die History der Relation schauen, wer den outer entfernt hat
=> den Kollega anfunken: "Was geht ab?"

auf Antwort warten und gemeinsam reparieren

Keine Antwort erhalten => selbst flicken

🙂

Ciao,
Frank

Das ist die Schwule Methode...

die echte Männer-Methode ist, das man es selbst wieder hinbiegt, und schaut wer das verbrochen hat und diese Person anschnauzt

Da aber openstreetmap von der OSMF heruntergewirtschaftet wird, kann man nicht mal herausfinden wer die scheiße verbrochen hat.

Entschuldigung, es dauerte zu lange die Daten für den/die Weg mit der ID 111601728 abzurufen.

JOSM und Potlatch sind auch kackprogramme... jedes CAD Programm kann flotter mit zig Millionen Punkte umgehen während JOSM immer lahmer und unbenutzbar wird und bei Potlacht das Flash Plugin abstürzt.

edwin-ldbg wrote:

JOSM und Potlatch sind auch kackprogramme... jedes CAD Programm kann flotter mit zig Millionen Punkte umgehen während JOSM immer lahmer und unbenutzbar wird und bei Potlacht das Flash Plugin abstürzt.

Da muss ich Dir Recht geben. Was QGIS in ein paar Sekunden lädt, kann bei JOSM Minuten dauern. Und bei JOSM ist das danach eigentlich nicht mehr benutzbar wenn es eine gewisse Größe überschreitet. Würde mich auch mal interessieren warum das so ist.

... ja das ist mir als relativer OSM Neuling auch aufgefallen. Auf der einen Seite ist das ja gerade das positive an OSM dass jeder ohne Vorkenntnisse gleich mal loslegen kann aber auch gleich mal versehentlich oder auch absichtlich Sachen löschen kann. Das wiederherstellen ist oft nicht gerade trivial und bisher auch schlecht umgesetzt und dokumentiert. Ich habe sogar meine Probleme damit rauszufinden was überhaupt gelöscht wurde. Das mit dem Validator in Josm geht ja nocht wenn jemand einen Teil eines MP oder einer Relation gelöscht hat, wenn aber eine ganz normale Fläche gelöscht wurde, meckert der Validator ja nicht und es ist dann ja nicht ganz leicht das gelöschte Teil zu finden.

Ich habe eher durch Zufall den User gefunden, dann in den Changesets nach gelöschten ways mit landuse=forest gesucht .... dann funktionierte die OSM History nicht wegen Timeout, dann dauert das Laden der gelöschten Fläche ewig und ist mindestens 30 mal abgebrochen und war dann auch irgendwie nicht vollständig. Ich habe den User jetz mal angemailt, evt. war es ja auch seine Absicht und er will das Gebiet neu mappen ...

Irgendwie ist die Vorgehensweise da noch nicht schlüssig gelöst. Dadurch, dass ich mein Interessengebiet mehr als auswendig kenne da ich dort schon 30 Jahre lang Rad fahre fällt mir halt jeder Fehler direkt auf, erst recht seit ich die Karte jeden Tag mit den Aktualisierungen neu rendere und mir die Änderungen anzeigen lasse des letzten Tages.

Da wird fast jeden Tag irgendwas aus Versehen gelöscht. Besonders bei den großen zusammenhängenden Waldgebieten wie dem Pfälzerwald mit recht großen MP kommt das recht oft vor. Da müsste es doch irgendwie eine Art koordinierte Qualitätskontrolle geben.

edit: Danke auch an Edwin für die Reparatur 🙂

es macht schon Sinn, dass die Möglichkeit des Reverts nicht groß propagiert wird. Man kann damit mehr zerstören als man durch die Nutzung repariert. Man sieht halt kaum was man macht. Ich repariere lieber manuell und würde es auch jedem empfehlen lieber manuell zu arbeiten. Jaja, ich habe es es heute benutzt um eine mutwillig gelöschte Staatsgrenze wieder zurück zu holen. Aber das Changeset bestand nur aus Vandalismus und sonst war auch nichts, das tangiert wurde. Gelöschte Staatsgrenzen und einmal als ich 10.000 DupNodes produziert habe, waren die einzigen Male, wo ich revertet habe, also etwa einmal pro 250.000 Nodes.

Moin Moin,

tja, war wohl pures Glück, als ich keine 10 min für das Finden der Ursache + Verursacher gestern brauchte.
Und das bei meinem kleinen Netbook und langsamer Internetleitung 😉

Ein CAD-Programm (qgis?) bringt mir in diesem Fall gar nix, da dies keinen Validator hat.

Übrigens wurde das outer bereits am Di/Mi gelöscht: Ein Grund mehr, den Validator häufig zu benutzen als "nur" in die Karte
zu schauen, welches bei z. B. falschen Abbiegerelationen keinen 'Fahndungserfolg' haben dürfte.

Vermutet man ein MP als Ursache, lohnt sich es sich auch, die MP-Überprüfung des OSM Inspektor (http://tools.geofabrik.de/osmi/) zu benutzen, die IMHO derzeit noch schärfer bzgl. MPs ist als der JOSM-Validator.

Ist es kein MP und will man sich Potlatch nicht antun, kann man auch einen Blick auf OWL (http://matt.dev.openstreetmap.org/owl_viewer/) werfen für den entsprechenden Bereich.

Es gibt eine englischsprache JOSM-Entwicklermailingliste (josm-dev), da kann man Fragen bzgl. Geschwindigkeit gerne mal stellen, hat auch nicht viel Traffic.

Ciao,
Frank

tja, war wohl pures Glück, als ich keine 10 min für das Finden der Ursache + Verursacher gestern brauchte.
Und das bei meinem kleinen Netbook und langsamer Internetleitung

Selbst reparieren hast es aber in Minuten nicht können.

Die echte Ursache ist, das jemand den ungenau eingezeichneten Landsat Wald gelöscht hat, um selbst mit Bing den neu einzuzeichnen. Beim von mir wieder hergestellten Wald gab es dann Überlappungen mit den neuen Waldstücken, so das der Landsat Wald aufgeschnitten, gelöscht und neu zusammengebunden werden musste, damit er mit den neuen Waldstücken nicht kollidiert. Ein Haufen toter Multipolygons Inner. Wohngebiete und Parkplätze die aus nicht geschlossenen Wegen bestehen. Das ganze Datenmodell für Flächen ist Mist. Das sollte als extra Layer getrennt sein.

Ein besseres Datenmodel für Flächen wäre so eine Oberfläche wie bei einem Grafikprogramm, ohne diesen ganzen Multi-Hyper-Polygonmist wo die Fläche aus dem Umriss definiert wird. Besser wäre der Wertzustand für ein feines Gitternetz ohne Schnittpunkte zu Wegen und ohne die ganzen hässlichen Effekte, extremst aufwendig verbundene Flächen wie bisher bearbeiten zu müssen.

edwin-ldbg wrote:

...
Ein besseres Datenmodel für Flächen wäre so eine Oberfläche wie bei einem Grafikprogramm, ohne diesen ganzen Multi-Hyper-Polygonmist wo die Fläche aus dem Umriss definiert wird. Besser wäre der Wertzustand für ein feines Gitternetz ohne Schnittpunkte zu Wegen und ohne die ganzen hässlichen Effekte, extremst aufwendig verbundene Flächen wie bisher bearbeiten zu müssen.

Eine (überwiegend) sachliche Aussage von edwin 😎 , die zudem zeigt, dass auch Powermapper unzufrieden mit unserem Datenmodell sind und über Verbesserungen nachdenken, weil die Fehleranfälligkeit zu hoch ist 😛