Wichtige Strassen die noch nicht neu gemappt worden sind ....

aighes · 2012-04-13T17:19:51.000Z

Was heißt Angst machen…das ist die Realität. Jeder Mapper muss selber für sich entscheiden, was er an Daten hochlädt und was er damit anrichtet. Und die Konsequenz könnte in diesem Fall sein, dass man einen Lizenzverstoß begeht. Ob das dann für den Mapper juristische Folgen hat weiß keiner. Es gibt durchaus Nichtzustimmer, die den Prozess genau beobachten und sicherlich nicht zögern bei Unstimmigkeiten. Deshalb halte ich es für gerechtfertigt auf den Umstand hinzuweisen, dass das Setzen von odbl=clean in der Auswirkung nicht vergleichbar mit dem Setzen von building=yes ist.

Zu deiner Frage: Löschen und neu einzeichnen darfst du immer. Aus meiner Sicht sind deine 4 Quellen im Sinne des Lizenzwechsels ok. Letzteres aber wohl mit Sicherheit nur, wenn der Zustimmer nicht bloß einen Tippfehler korrigiert hat. Also bspw. nicht aus building=ys building=yes gemacht hat. Oder aber du weißt, dass er diese Info eigenständig erhoben hat.

Rbg_Hessen · 2012-04-13T17:56:14.000Z

Letzteres aber wohl mit Sicherheit nur, wenn der Zustimmer nicht bloß einen Tippfehler korrigiert hat.

Das kann man aber doch über das Versionsprotokoll abklären /Absichern

Um bei meinem Beispiel zu bleiben :

Wenn der“ Nichtzustimmer“ im Jahre 2008 kein Ref gesetzt hat .
und dann ein „Zustmmer“ in 2011 Ref = L 0815 eingetragen hat ,
dann kann man doch das Ref = L 0815 als „aus sicherer“ Quelle annehmen oder ?

aighes · 2012-04-13T18:27:51.000Z

Ja…ist ja eine eigenständige Information. Hätte der Ersteller aber ref=L0815 getaggt und ein Zustimmer daraus ref=L 0815 wäre es nicht mehr unbedingt so.

EvanE · 2012-04-13T18:55:06.000Z

aighes:

Ja…ist ja eine eigenständige Information. Hätte der Ersteller aber ref=L0815 getaggt und ein Zustimmer daraus ref=L 0815 wäre es nicht mehr unbedingt so.

Dem ist zuzustimmen, eine Schreibkorrektur hat keine eigene Schöpfungshöhe. Vieles wird ja auch von Bots erledigt.

Eine andere Situation liegt vor, wenn ein Ablehner ref=L 130 eingetragen hat und ein Zustimmer das zu ref=L 123 korrigiert hat. Das ist eine Änderung, die nur durch eigene Kenntnisse möglich ist.

Wie auch immer gehe ich den Feinheiten des Clean/Not Clean aus dem Weg, in dem ich lieber etwas zuviel neu erfasse und notfalls die Information, die ich nicht habe, einfach weglasse.

Edbert (EvanE)

SunCobalt · 2012-04-13T19:39:36.000Z

EvanE:

Wie auch immer gehe ich den Feinheiten des Clean/Not Clean aus dem Weg, in dem ich lieber etwas zuviel neu erfasse und notfalls die Information, die ich nicht habe, einfach weglasse.

+1 Mir ist das odbl=clean auch suspekt. Ich verstehe bis heute nicht, wozu man das braucht. Wenn man die Kenntnis und Mittel hat, kann man das Objekt neu erstellen. Wenn nicht, ist odbl=clean nicht angebracht.

EvanE · 2012-04-13T19:51:21.000Z

SunCobalt:

EvanE:

Wie auch immer gehe ich den Feinheiten des Clean/Not Clean aus dem Weg, in dem ich lieber etwas zuviel neu erfasse und notfalls die Information, die ich nicht habe, einfach weglasse.

+1 Mir ist das odbl=clean auch suspekt. Ich verstehe bis heute nicht, wozu man das braucht. Wenn man die Kenntnis und Mittel hat, kann man das Objekt neu erstellen. Wenn nicht, ist odbl=clean nicht angebracht.

Naja, bei einer Haltestelle, die von x Buslinien angefahren wird, ist es z.B. sehr mühsam das neu zu erfassen und in allen Relationen nachzutragen. Da ist ein odbl=clean als Bestätigung, dass die Informationen auch von mir aus eigenem Wissen so erfasst worden wären, doch schon deutlich einfacher.

Ich selber habe das nur bei einer Kreuzung gemacht, die von einem anonymen User erstellt worden war. Die war in einer Routenrelation enthalten, ich kannte sie und mir fehlte das Umfeld, um die Geometrie sicher neu erfassen zu können.

Edbert (EvanE)

aighes · 2012-04-13T20:08:47.000Z

Es war halt für die gedacht, die das Objekt irgendwann komplett neu erfasst haben, aber auf Grund des Erhalts der History die alten Nodes etc. wieder verwendet hatten.

EvanE:

Da ist ein odbl=clean als Bestätigung, dass die Informationen auch von mir aus eigenem Wissen so erfasst worden wären, doch schon deutlich einfacher.

Genau das ist es eben nicht. Du musst dieses Objekt komplett unabhängig erfasst haben. Bsp.: Das war mal ein Ampel-Node und du hast daraus eine Bushaltestelle gemacht.

Oli-Wan · 2012-04-13T20:12:43.000Z

SunCobalt:

Mir ist das odbl=clean auch suspekt. Ich verstehe bis heute nicht, wozu man das braucht.

Zum Beispiel für die oben schon angesprochenen Rechtschreibkorrekturen - der Bot wird längst nicht alle derartigen trivialen Edits als solche erkennen können. Wenn das die einzige “Beeinträchtigung” eines Objekts ist, kann man odbl=clean guten Gewissens setzen.

Rbg_Hessen · 2012-04-13T20:14:34.000Z

EvanE:

…, dass die Informationen auch von mir aus eigenem Wissen so erfasst worden wären, doch schon deutlich einfacher.
… mir fehlte das Umfeld, um die Geometrie sicher neu erfassen zu können.
Edbert (EvanE)

Ihr macht es den Unsicheren nicht gerade einfach,

Was sollen wir glauben wenn ihre erfahrenen Hasen euch schon nicht einig seid?

aighes:

Wenn du garantieren kannst (und dafür dann auch gerade stehst), dass keine Daten von einem Nichtzustimmer abgeleitet wurden. odbl=clean bedeutet nicht: “Hätte ich auch so gekonnt” oder “Passt so” oder “Stimmt mit Bing und den Tracks überein”.

P.S: Was mach ich mit einem einzelnen Knoten einer Kreuzung
(Bestandteil mehrere Relationen und Routen) der noch
Von einem Nichtzustimmer über ist
Wird aber in der Lizenzprüfung von Josm nicht mehr bemängelt

aighes · 2012-04-13T20:15:24.000Z

Oder aber ein Nichtzustimmer hat mal ein Tagg gesetzt. Dieses löscht du und setzt dann, wenn dann alles ok ist odbl=clean.

fx99 · 2012-04-13T20:16:11.000Z

Ich sehe die Hauptanwendung von odbl=clean darin, dass Mapper, die sowohl OdBL kompatible als auch inkompatible Daten beigetragen haben, und deshalb der CT nicht zustimmen können, die kompatiblen Daten (unter einem anderen account) doch unter ODBL stellen können.

aighes · 2012-04-13T20:17:47.000Z

Rbg_Hessen:

P.S: Was mach ich mit einem einzelnen Knoten einer Kreuzung
(Bestandteil mehrere Relationen und Routen) der noch
Von einem Nichtzustimmer über ist
Wird aber in der Lizenzprüfung von Josm nicht mehr bemängelt

Die LWG hat sich dazu entschlossen, leere Nodes von Nichtzustimmern, die anschließend verändert wurden als OK einzustufen, weil dieser leere Node keine Schöpfungshöhe hat.

EvanE · 2012-04-13T21:26:55.000Z

Rbg_Hessen:

Ihr macht es den Unsicheren nicht gerade einfach,
Was sollen wir glauben wenn ihre erfahrenen Hasen euch schon nicht einig seid?

In diesem Fall dich nach aighes richten.
Nachdem ich den Text von http://wiki.openstreetmap.org/wiki/Tag:odbl%3Dclean nochmal in Ruhe durchgelesen habe, muss ich aighes Interpretation zustimmen und meine Eigene verwerfen.
Ein Glück, dass der Knoten gemäß dem Lizenz-Plugin bereits als Clean galt.

Rbg_Hessen:

P.S: Was mach ich mit einem einzelnen Knoten einer Kreuzung
(Bestandteil mehrere Relationen und Routen) der noch
Von einem Nichtzustimmer über ist
Wird aber in der Lizenzprüfung von Josm nicht mehr bemängelt

Wenn der Knoten in der Lizenzprüfung nicht mehr markiert wird, brauchst du wegen des Knoten nichts mehr zu machen.

Im allgemeinen Fall (der Knoten ist noch markiert) gehst du wie folgt vor:
a) Notieren in welchen Relationen der Knoten als Member enthalten ist.
Ob einer der Wege in einer Relation ist, ist für den Knoten unbedeutend.
b) In jeden Weg, der mit diesem Knoten verbunden ist, kurz vor dem Knoten
einen zusätzlichen Knoten einfügen.
c) Den Kreuzungsknoten löschen. Du hast jetzt mehrere unverbundene Wege.
d) Einen der in b) erstellten Knoten an die richtige Stelle schieben und
anschließend alle übrigen Endknoten mit diesem vereinen (M wie Merge).
e) Falls der alte Knoten Mitglied in Relationen war, den neuen Knoten wieder
in die Relationen einfügen.
Fertig!

Edbert (EvanE)

Tronikon · 2012-04-14T06:59:06.000Z

Noch ein kleiner Optimierungsvorschlag zum Vorgehen, wie es EvanE beschrieben hat

a) Notieren in welchen Relationen der Knoten als Member enthalten ist.
Ob einer der Wege in einer Relation ist, ist für den Knoten unbedeutend.
b) In jeden Weg, der mit diesem Knoten verbunden ist, kurz vor dem Knoten
einen zusätzlichen Knoten einfügen.
c) Den Kreuzungsknoten löschen. Du hast jetzt mehrere unverbundene Wege.
d) Einen der in b) erstellten Knoten an die richtige Stelle schieben und
anschließend alle übrigen Endknoten mit diesem vereinen (M wie Merge).
e) Falls der alte Knoten Mitglied in Relationen war, den neuen Knoten wieder
in die Relationen einfügen.

Man kann sich mit JOSM das Notieren der Relationen auch sparen:

a) In jeden Weg, der mit diesem Knoten verbunden ist, kurz vor dem Knoten einen zusätzlichen Knoten einfügen.
b) Falls der zu löschende Knoten in Relationen enthalten ist:
b1) Diesen Knoten und einen der in a) erstellten Knoten gleichzeitig (Shift-Mausklick oder Ctrl-Mausklick) auswählen,
b2) unter “Eigenschaften” mit Doppelklick einzeln jede der angezeigten Relationen zum Bearbeiten auswählen und Folgendes tun:
b2-1) Mit “Alle Objekte aus dem aktuell ausgewählten Datensatz nach dem letzten ausgewählten Mitglied einfügen” den neuen Knoten einfügen.
b2-2) Gegebenenfalls die Rolle für den neu eingefügten Knoten ergänzen (selbe Rolle wie zu löschender Knoten.)
c) Den Kreuzungsknoten löschen. Du hast jetzt mehrere unverbundene Wege.
d) Einen der in a) erstellten Knoten an die richtige Stelle schieben und anschließend alle übrigen Endknoten mit diesem vereinen (M wie Merge).

Man kann statt Schritt b) die Relationsmitgliedschaften auch komplett mit dem utilsplugin2 (“Relationen einfügen”) vom alten auf einen der neuen Punkte übertragen. Dann stimmt aber die Position des neuen Punkts in den Relationen nicht mehr (wird ganz hinten eingefügt). Dafür wird die Rolle korrekt übertragen. Wenn die Position also nicht wichtig ist, ist das die Methode der Wahl.

Bei den Relationsmitgliedschaften gilt natürlich wie bei allen anderen Merkmalen des Punktes, dass man sie aus “CT-sauberen Quellen” ableiten muss.

Tronikon

EvanE · 2012-04-14T12:41:21.000Z

Tronikon:

Noch ein kleiner Optimierungsvorschlag zum Vorgehen, wie es EvanE beschrieben hat
…
Man kann sich mit JOSM das Notieren der Relationen auch sparen:
…
… utilsplugin2 …

Bei den Relationsmitgliedschaften gilt natürlich wie bei allen anderen Merkmalen des Punktes, dass man sie aus “CT-sauberen Quellen” ableiten muss.

Hallo Tronikon

Alles richtig.
Ich wollte die Dinge nur in den Grundzügen beschreiben. Deine Optimierungen sind dann individuelle Arbeitsweisen, die man entwickelt, sobald man solche Änderungen mehrfach macht.

Sehr wichtig finde ich deinen Hinweis auf die CT- und ODBL-kompatiblen Quellen.
Neben dem unmittelbaren eigenen Wissen können das auch Informationen aus anderen (CT-/ODBL-konformen) Mitgliedern der Relation sein.

Im Fall von Routen z.B. die davor und dahinter liegenden Mitglieder.
Bei Abbiege-Beschränkungen ergibt sich das Via in der Regel aus den From- und To-Membern.
Bei einer Site-Relation ergibt sich das meist aus der Lage eines Objektes.
…

Edbert (EvanE)

Rbg_Hessen · 2012-04-14T15:14:36.000Z

Tronikon:

Wenn die Position also nicht wichtig ist, ist das die Methode der Wahl.

Hallo,

wann ist die Reihenfolge den wichtig ?

Ich bin jetzt schon über einige Relationen gestolpert die sehr
„durcheinander“ sind.
Das ist für die Übersicht eines
Beginer oder Widereinsteiger nicht gerade förderlich.
Ist das sortieren erlaubt / angebracht?

Jimmy_K · 2012-04-14T16:09:57.000Z

Bei Routen wie Straßen, Radwege, öffentlichen Verkehrsmittel* sollte die Reihenfolge eingehalten werden. Bei Multipolygonen ist es z.b. egal.

*) Zuerst Strecke, dann Haltepunkt+Bahnsteig und dann nächster Haltepunkt+Bahnstein.

EvanE · 2012-04-14T16:55:39.000Z

Jimmy_K:

Bei Routen wie Straßen, Radwege, öffentlichen Verkehrsmittel* sollte die Reihenfolge eingehalten werden. Bei Multipolygonen ist es z.b. egal.

*) Zuerst Strecke, dann Haltepunkt+Bahnsteig und dann nächster Haltepunkt+Bahnstein.

Kleine Ergänzung:
Besteht bei Multipolygonen ein Inner- oder Outer-Ring aus mehreren Wegen, so scheint es mir sinnvoll diesen Ring in eine Reihenfolge zu bringen, die der Abfolge der Wegstücke entspricht. Besonders wichtig ist das bei Grenzen, die als Multipolygon erfasst sind.

Ich persönlich sortiere bei Multipolygon-Relationen zudem zur besseren Übersicht die Outer nach vorne und die Inner nach hinten. Da gibt es außer der besseren Übersicht jedoch keinen anderen Grund für. Ebenso sortiere ich Abbiege-Beschränkungen in die Fahrtrichtung, also from - via - to. Das alles natürlich nur, wenn ich eine Relation erstelle oder sowieso ändere.

In Summe verbessert eine sinnvolle Reihenfolge immer die Übersicht.
Anwendungen müssen im Allgemeinen auch mit nicht oder ‘falsch’ sortierten Relationen umgehen können.

Es gibt auch Relationen für die keine ‘natürliche’ Ordnung existiert z.B. site-Relationen.

Edbert (EvanE)

Rbg_Hessen · 2012-04-14T22:41:21.000Z

So,
ich denke ich habe es einigermaßen verstanden mit den Routen.

Schaut sich bitte mal jemand von euch die Line 159588073 an.

Die habe ich in Rodenbach neu erstellt ,
ob das so stimmig ist.
Die „alte“ war auch Bestandteil der vier Routen.
Das mit dem „link“ in der einen Rolle habe ich noch nicht verstanden aber wieder so eingesetzt
Danke Gruß

Haynes · 2012-04-14T22:59:43.000Z

nachdem nun die Frage nach dem odbl=clean geklärt ist, könnte mir eventuell jemand mit diesem Bereich helfen?
Die Wege benutzen die gleichen Punkte wie die angrenzenden Flächen. Das macht das neu mappen zwar vergleichsweise einfach, da die Flächen bereits vorher da waren, allerdings schaffe ich es nicht die Wege auszuwählen um sie zu löschen.
Kann mir vielleicht jemand sagen wie ich das mit JOSM anstelle? Ich hab es bisher immer nur geschafft die ganzen Flächen auszuwählen