Mein erster Versuch mit JOSM endete auch mit einem doppelten Dorf. Ich dachte mir, es sei eine gute Methode, Hausnummern zu tagen, hatte aber statt eines Nodes ein ganzes Gebiet in der Auswahl. Das hab ich dann eingefügt, eine Hausnummer geändert, das Dorf erneut eingefügt … ich glaub beim dritten Mal fiel es mir dann auf und ich hab in Panik den Editor geschlossen. In Panik könnte ich aber auch mit Hochladen reagieren 
Grüße, Max
Du meinst das Duplizieren von Objekten mit Ctrl-D? Das führt typischerweise zu verschobenen Objekten, eingefügt am Ort des Cursors. Hier und in dem anderen beschriebenen Fall liegen die Duplikate aber haargenau auf dem Original, sonst wären sie mir gar nicht aufgefallen.
Nachtrag: Ich habe soeben Antwort vom Ersteller erhalten, er wird sich selbst darum kümmern.
Ich frage mich aber weiterhin, wie solche Fehler überhaupt entstehen.
Ich habe es ab und an mal, das JOSM nach dem von Konflikten Elemente doppelt anlegt.
Andere haben das mit Potlatch auch schon hinbekommen, die Ursache dafür kenne ich nicht.
Mit Keepright fällt das sehr schnell auf, und für soetwas hatte ich mir die xy-Bot Erweiterung im entsprechenden Thread gewünscht.
Das passiert ganz leicht (unabhängig vom Editor), wenn beim Hochladen Konflikte entstehen.
Die bereits hochgeladenen Elemente werden in der Situation nicht zurückgemeldet. Das heißt sie können auch nicht im Editor als hochgeladen registriert werden. Wenn man nach dem Beseitigen der Konflikte, ein zweites mal hochlädt, werden diese Elemente ein zweites (drittes, …) Mal hochgeladen. Bei neu angelegten Objekten entstehen dabei die Duplikate, da es ja noch keine Version gibt, gegen die geprüft werden kann.
In JOSM gibt es dafür die Funktion Daten aktualisieren (im Menü Datei). Das kann und sollte man bei größeren Edits vor dem Hochladen ausführen. Dabei werden alle Konflikte angezeigt und können (vor dem Hochladen) beseitigt werden. Gegebenenfalls Daten aktualisieren zur Sicherheit danach noch einmal wiederholen.
Falls man bereits einen Teil hochgeladen hat, vor dem erneuten Hochladen (in JOSM) die Fehlerprüfung starten. Dabei werden doppelte Objekte leicht gefunden. Dabei zuerst Wege mit ID=0 (= neue Objekte) löschen. Dabei werden auch doppelte Knoten aufgrund doppelter Wege mit entfernt. Lediglich die Knoten, welche mit anderen Objekten verbunden sind oder allein stehen, muss man dann noch einzeln löschen.
Edbert (EvanE)
Alles schön und gut, aber wie kriegt man es hin, Bestandsobjekte an gleicher Stelle zu duplizieren? Also aus Objekten, die bereits beim Herunterladen des Gebiets existierten (ID > 0), neue und völlig identische Objekte (ID = 0) zu generieren und anschließend hochzuladen? Noch dazu, ohne daß JOSM sich über die doppelten Knoten (u.a.) beschwert?
Es geht im Beispiel um etliche Straßen samt ihrer Knoten. Ich würde ohne nachzusehen wetten, daß die nicht allesamt zur gleichen Zeit von jemand anderem bearbeitet wurden, sodaß Konflikte hätten entstehen können. Im anderen Fall waren es landuse-Flächen, die noch im Originalzustand aus dem Import waren, die selbst später nie wieder jemand angefaßt hat.
Der Revert aller drei Changesets ging ohne Probleme über die Bühne, eine Aktualisierung des Browsercaches etwa 20-30 Minuten danach lieferte die reparierten Relationen, die unvollständige landuse=field ist weg
Ist zu mir zu heikel bezog sich auf die Busrelation
Bernd
Ganz einfach! Man habe keine gute Internetverbindung. Dann lädt man einfach den bereich herunter und verändert die Daten. Dann lädt man die Objekte hoch und wenn es scheitert noch zwei dreimal bis der Editor sagt Erfolg. Ich habe das Gefühl dabei entstehen genau solche Duplikate. Die Dinger zu finden ist dann eine heiden Arbeit.
Was ist nun mit landuse=field? Fällt wohl unter die Kategorie jeder kann machen, was er will.
Auf diese Weise kann man neu erzeugte Objekte mehrfach hochladen, genau wie von Edbert auch schon beschrieben. Wenn der Editor im ersten Versuch für den Upload keine Bestätigung erhält, schiebt er die Objekte halt beim nächsten Versuch noch einmal hoch. Aber bestehende Objekte, die nicht verändert wurden, werden normalerweise gar nicht hochgeladen, wie es hier geschehen ist; Duplikate dieses Typs können also nicht auf diese Weise entstehen.
Bei einem offenen Projekt habe ich, ehrlich gesagt, keine Probleme damit, wenn mir ein Tag sinnvoll erscheint, nutze ich ihn.
Was anderes ist die Qualität des Mappings an sich, vor allem, wenn es gravierend falsch ist und der Ersteller keine Anstalten macht den Fehler zu beheben, dann sollte man es ASAP korrigieren.
bernd
Du brauchst den Konflikt nicht bei dem selbst betroffenen Objekt sondern irgendwann weit hinten im Changeset.
Gab es nicht irgendwie die möglichkeit Elemente aus einem JOSM layer in den anderen zu übernehmen?
Wenn die Daten in dem Gebiet dann in dem hochgeladenen Layer nicht heruntergeladen waren, werden auch keine Warnungen angezeigt.
Außerdem kann man Warnungen auch ignorieren.
Es kommt eben darauf an, was man unter offen versteht.
Für mich heißt offen, jeder kann sich daran beteiligen, aber nicht con gusto, sondern nach klaren Regeln. Wer meint, sich seine eigene OSM-Welt schaffen zu müssen, sollte dies auf der Grundlage des Originals mit einem eigenen Server zu tun.
Wenn z.B. in OSM Flächen in Wäldern mit landuse=grass + name=Rodung gemappt und der Username ‘…förster’ lautet, habe ich einen leisen Verdacht.
Du kannst einfach nicht verhindern, dass Leute Fehler eintragen. Auch wenn du feste Regeln für Tags hast, die verwendet werden dürfen und einer API, die das überprüft, kann jeder ein landuse=grass + name=Rodung eintragen. Von dem Aufwand in der API mal ganz zu schweigen.
Hallo viw,
mit der duplicate nodes map war es ein Leichtes, solche doppelten Objekte zu finden (ein Haufen vieler roter Punkte). Damit hatte ich ich den letzten Jahren zeitweise große Teile Deutschlands sauber bekommen. Aber, die Karte lieferte dann eines Tages im Sommer (etwa 18-20 Monate her) keine Tiles mit den roten Punkten mehr aus - nur die normale Mapnik-Hintergrund-Karte war noch da.
Ich konnte auch erkennen, dass der erste Upload an neuen Daten (mit JOSM) keine Antwort brachte, oder der User ungeduldig wurde, weil der Server damals manchmal recht lange für die Antwort brauchte und das Fenster, das den Status des Hochladens anzeigt, geschlossen hatte und erneut hochlud, denn die älteren der doppelten Daten zeigten eine Zeit zwischen “Erstellt” und “Geschlossen” des Änderungssatzes von genau bis gut einer Stunde (Der Timeout bei einem offenen Changeset beträgt ja nach Ende des Hochladens, bei fehlendem Schließen, eine Stunde), während der jüngere der doppelten Wege und Knoten bei dieser Zeit meist deutlich unter wenigen Minuten lag. Wenn man auf solch eine Antwort des Servers lange wartet, kann man schon im Browser nachsehen, ob ein Weg, den man verändert hat, einen Zeitstempel von nach dem Beginn des Hochladens und den eigenen User-Namen trägt.
Ich wünsche mir diese Karte gerne zurück - gab es da Pläne von Matt (dem Autor), diese Karte als eine der Zeilen im Layer-Switcher der Mapnik-Karte einzubauen? - aber mit keepright sollte es auch gehen (diese schrägen gelben Fragezeichen).
Ergänzende Grüße,
Franz
Ich habe mir da wieder mal was eigenes gebastelt und damit in den letzten Wochen NRW weitestgehend aufgeräumt (größter verbliebener Schandfleck: Aachen). Ein kleines Skript, das aus einem .osm.bz2 jeweils einen der mehrfachen Knoten heraussortiert. Damit kann man sich noch nicht direkt an die Duplikatbeseitigung machen, aber man kann eine Ebene mit diesen Knoten quasi als Hintergrund in JOSM einsetzen, sieht sofort die Hotspots und muß nicht mehr zwischen JOSM und Brauser hin und her wechseln, da herumscrollen und so weiter. Ist alles quick & dirty gebastelt, nicht allzu schnell und nicht so elegant wie eine Online-Map in Quasi-Echtzeit, aber erfüllt seinen Zweck. Könnte ich zur Verfügung stellen, falls Interesse besteht. (Ist allerdings auf Linux zugeschnitten, unter Windows wären vermutlich ein paar Verrenkungen nötig.)
Das sollte bzw. muß man aus meiner Sicht leider noch weiter unterscheiden bzw. aufsplitten, weil es müssen ja u.a. folgende Unterscheidungen gemacht werden:
Die landschaftliche Prägung: Eine natürliche Anhäufung von Sand wird ja nicht automatisch immer zur Wüste, es kann z.B. auch eine Heidelandschaft sein. (Strand ist dagegen eine Nutzung einer größeren natürlichen Sandfläche.)
Der natürliche Untergrund: z.B. Stein/Fels, Sand, Erde.
Der evtl. vorhandenen Bewuchs auf dem Untergrund: Moose, Flechten, Gräser (einschließlich “Gras”), Kräuter, Sträucher/Büche, (spezielle) Bäume, spezielle Pflanzen (crop=*).
Auf dem natürlichen Untergrund (genaue Abgrenzung bei z.B. Gewässern/Gletschern?) vorhandenen natürliche/künstliche Auflagen: Gletscher, Schotter, Beton, Asphalt.
Irgendwie scheinen selbst diese paar Punkte kategoriemäßig schon weiter aufzulösen als z.B. das DLM, andere nennenswerte Modelle habe ich gerade nicht gefunden.
Dann kommt natürlich die Nutzung der Fläche: alleinige Nutzung, kombinierte Nutzung, weiter untergliederte voneinander abhängige Nutzungen.
landcover=grass ist z.B. kein landcover, sondern $bewuchs (aber in natural=* ist ja auch alles mögliche drin), landcover wäre da z.B. ground.
Dann ist nicht klar, was surface=* genau meint, weil die Wegoberfläche, für die der Tag benutzt wird, kann wahlweise natürlich oder künstlich sein. Eine Wiese mit einem Track ist landcover=ground mit zusätzlichem $bewuchs=grass außerhalb des Tracks.
Klarere Trennung zwischen Bedeckung und Nutzung (z.B. Wald, Wiese,… versus Agrarwirtschaft, Bebauung, Militär, …) halte ich für sinnvoll und machbar , aber Landuse 2.0?
Sorry, aber das tu ich mir nicht an.
Gruss
walter
+1 Ich kann’s auch nicht mehr hören.
“Wir mappen die Realität” : Dann müsste man jedes Atom einzeln mappen… Ob dann noch 'ne nutzbare Karte dabei
rauskommt?
Geht’s noch?
@Fabi2: Ähmm…ja…und wenn der Sandhaufen von Holz umgeben ist und Förmchen drin liegen ist es ein Sandkasten/Spielplatz. 
Diese Landschaftsformen sind besser in natural=* aufgehoben. Bspw. wäre dann ein natural=beach landcover=“Kies” ein Kiesstrand und natural=beach landcover=sand ein Sandstrand und so weiter. landcover beschriebt eher das, was auf dem Luftbild sehen würde. Klar, man kann das auch weiter treiben und den pH-Wert des Bodens eintragen. Ich sehe aber darin keinen Vorteil