Multipolygon-Reparaturen koordinieren?

Ich schau immer mal wieder bei OSMI vorbei und korrigiere MP's im Bereich Oberrheingraben/Schwarzwald zwischen Basel und Karlsruhe. Da sind wir ziemlich sauber. Bei den touching inner besteht aber noch in Richtung Schwobe-Ländle gewisser Handlungsbedarf und da überschreite ich hin und wieder die Grenze und helfe aus. Das hängt aber vom Ausmaß meiner Langeweile ab, denn die touching inner sind zwar unschön aber bis zu einem gewissen Grad erträglich.

Koordination halte ich nicht für erforderlich. Allerdings könnte ich mir vorstellen, dass man vernachlässigte Gebiete lokalisiert und hier zum Großputz anbietet.

Ich versuche die Schweiz und Lichtenstein sauber zu halten. Dabei erledige ich häufig auch grenznahe Fehler in den Nachbarländern.

Generell hohe Aktivität ist beim Beseitigen von Geometry Fehlern festzustellen.

Etwas vernächlässigt werden die Tagging Fehler. Dabei sind sie (wenn man FIXME" abschaltet) in der Regel sehr einfach zu beheben. Die meisten Fehler sind auch schon recht alt (vor 2011).
Die "Ways without tags" lassen sich mit Luftbilder sehr einfach behebden. Häufig befinden sich die Tags sogar schon an einem der Nodes (statt am way) und man muss sie nur kopieren.

Zum Schluss kümmere ich mich noch die Routing Fehler.

Hi,
habe vor wenigen Monaten angefangen, in süd-NRW Fehler zu korrigieren. Dann ging es Richtung Nord- und Ostsee. Seit dem 1. April habe ich nichts mehr gemacht, da ich täglich auf das Große löschen warte. 🙂

Was ich nicht kann, ist Grenzen zu flicken (bis auf die offensichtlichen).

Einen Austausch der Techniken kann sicher nicht schaden, hätte mir anfangs (und vielleicht auch jetzt noch) viel Zeit ersparen können. 🙂

P.S.: bis vor einiger Zeit wurden die Änderungen im OSMI alle 24-48 h aktuallisiert. Heute am 23.4. steht das Datum vom 19.4. drunter. Schätze also, dass frühestens nach 2, spätestens nach 4-5 tagen alle Änderungen sichtbar sind. Bei diesen "größeren" Abständen ist es sicher sinvoll sich abzusprechen oder Gebiete einzuteilen, denn es ist manchmal recht lästig nach Fehlern zu suchen, wo keine da sind (=andere schneller waren).
Wenn ich den OSMI schon anspreche, dann würd ich eine Aktualisierungsuhrzeit von "nachts" bevorzugen. Denn momentan tauchen die Änderungen von nach 19:15 erst mit 2-4 tagen Verzögerung auf. Geht natürlich nur, wenn es machbar und nicht zu umständlich ist!

MasiMaster wrote:

...Bei diesen "größeren" Abständen ist es sicher sinvoll sich abzusprechen oder Gebiete einzuteilen, denn es ist manchmal recht lästig nach Fehlern zu suchen, wo keine da sind (=andere schneller waren).
...

Ich klicke dann immer erst die History (Sanduhr) des Fehlers an. Wenn dort das Datum der letzten Version in der History aktueller wie das lastchange-Datum des Fehlers und das Aktualisierungsdatum bei OSMI ist, war jemand schneller.

Oli-Wan wrote:

Geschätzt ein Dutzend Leute in DE befassen sich u.a damit, systematisch kaputte Multipolygone (wie von OSMI angezeigt) zu flicken, und soweit ich es überblicken kann, scheinen sie alle dieses Forum zu verfolgen.

Ich lasse die Finger von Multipoligonen soweit es mir möglich ist. Leider stosse ich doch ab und zu auf MPs, die etwas zu korrigieren hätten. Öfters mache ich dann die Korrektur nicht, um ja kein Auslaufen zu verursachen. Dabei frage ich mich jedesmal, gäbe es eigentlich nicht bessere Möglichkeiten anstelle eines MP. So frage ich mich, ob ein See nicht besser mit einzelnen Wasserflächen zusammengesetzt werden sollte, statt über ein MP. Dann würde nämlich nur die defekte Wasserfläche auslaufen und nicht der ganze See und es wäre offenslichtlich, wo man korrigieren muss.

Oli-Wan wrote:

Geschätzt ein Dutzend Leute in DE befassen sich u.a damit, systematisch kaputte Multipolygone (wie von OSMI angezeigt) zu flicken, und soweit ich es überblicken kann, scheinen sie alle dieses Forum zu verfolgen.

Ich möchte mal die Diskussion anstoßen, ob wir unsere Bemühungen besser koordinieren sollten, z.B. durch regionale oder thematische "Interessenschwerpunkte" und ggf. sogar Absprachen, wer sich um welches Gebiet kümmert. ...

Der offensichtliche Vorteil einer regionalen Aufteilung wäre die mögliche Effizienzverbesserung - man würde seltener Multipolygone aufrufen, die andere bereits in den letzten Tagen repariert haben.

Aber auch ohne irgendeine Aufteilung wäre mehr Kommunikation unter den Mitstreitern sicher hilfreich, ... Und wenn eines schönen Tages der CT-Putzbot eifrig löscht (und dabei u.a. MPs zerlegt), ließe sich ggf. eine konzertierte Aktion starten.

Es wäre sicher auch ganz interessant, überhaupt mal einen Überblick zu haben, wer eigentlich alles bei dem Thema mitmacht, und insbesondere wer die eigenen Nachbarn sind. ...

Hmmh, ob wir eine besondere Koordination für das Thema brauchen halte ich für fraglich.

Was in meinen Augen jedoch sinnvoll wäre, ist Regionen zu identifizieren, wo verstärkt problematische Relationen auftreten. Da kann man dann außerhalb seines üblichen Wirkungskreises gezielt nachsehen, ob man da etwas dran machen kann/will.

Solche Einträge sollten sinnvollerweise einen Link zur Multipolygon-Ansicht des OSMI und Verweise auf den Eintragenden und ggfs. Bearbeiter enthalten. Wer ein Gebiet einträgt, oder verbessert, sollte gelegentlich prüfen, wie der Zustand des Gebietes in der Zwischenzeit ist.

Nach der Lizenzbereinigung mit voraussichtlich vielen zusätzlichen Problemen wäre so eine Seite mit kritischen Gebieten und loser Koordinierung auf jeden Fall eine sinnvolle Sache.

Edbert (EvanE)

wyo wrote:

Dabei frage ich mich jedesmal, gäbe es eigentlich nicht bessere Möglichkeiten anstelle eines MP. So frage ich mich, ob ein See nicht besser mit einzelnen Wasserflächen zusammengesetzt werden sollte, statt über ein MP. Dann würde nämlich nur die defekte Wasserfläche auslaufen und nicht der ganze See und es wäre offenslichtlich, wo man korrigieren muss.

Da muß man m.E. ein bißchen unterscheiden. Eine Wasserfläche würde ich nicht in zwei angrenzende Flächen aufspalten, um die Insel in der Mitte auszusparen - schon allein, weil der See - und zwar der gesamte See - ja oft einen Namen hat. Das ist genau der Fall, wofür Multipolygone gedacht sind und da soll man sie meiner Meinung nach auch ohne Bedenken einsetzen. Andererseits entstehen viele kaputte MPs genau dort, wo sie ohne jede Not verbaut werden. Wenn ich das jetzt näher ausführe, driftet das Thema aber vermutlich wieder in eine Grundsatzdiskussion ab ;-) (Die Leute, die ich mit diesem Faden ansprechen will, wissen schon, was gemeint ist.)

Ich habe von Zeit zu Zeit die Multipolygone in ganz Norddeutschland im Blick.

Mein Schwerpunkt liegt da auf den administrativen Grenzen, da diese u.a. für die Orts- und Straßensuche der ausgereiften Navigationslösungen sehr wichtig sind.

Auch lassen sich oft neben den Grenzpolygonen auch PLZ-Gebietspolygone reparieren.

Hinweis dazu auch nochmal auf http://ags.misterboo.de

sowie http://wiki.openstreetmap.org/wiki/MapCSS/Examples
(wer findet nach diesem Schema mittels JOSM o.ä. auch noch in anderen Bundesländern die dort abgebildeten dunkelblauen(!) Grenzpolygone, wo definitiv Fehler vorliegen?)

PS: und wovor mir ja ganz DOLL graust:
In welchem Maße gehen uns beim Linzenzwechsel Grenzlinien und -Relationen flöten??????
Für Gemeinden?? Landkreise??? Bundesländer???

Ich kümmere ich Wesentlichen um BW. Da ist aber auch Radeln aktiv, es gibt meist wenig zu tun.
Deshalb schaue ich auch in das benachbarte "Ausland" : Bayern, RLP, HES, Schweiz, Austria.
Von Frankreich lasse ich die Finger, da ist ein richtiges Chaos.

Touching Inner sehe ich nicht als Fehler, deshalb lasse ich das so wie es ist.

stephan75 wrote:

PS: und wovor mir ja ganz DOLL graust:
In welchem Maße gehen uns beim Linzenzwechsel Grenzlinien und -Relationen flöten??????
Für Gemeinden?? Landkreise??? Bundesländer???

Bei Routen-Relationen sind etwa 5% problematisch (ca. 6.000 von 127.000).
Das sind jedoch nur die Zahlen durch Beiträge von Nichtzustimmern.

Probleme, weil Wege der Route entfallen, sind dabei nicht enthalten.
Ich schätze allerdings, dass dabei nicht mehr so viel dazu kommt, da oft die problematischen Wege vom Ersteller der Wege in die Routen-Relation eingetragen wurden (z.B. durch Split in JOSM).

Wie groß dabei der Anteil von komplett entfallenen Relationen ist lässt sich nur schwer schätzen.
Bei Grenzen kann das einiges ausmachen, da der unentschlossene User Mueck in dem Bereich ziemlich aktiv war. Und es sieht mE nicht mehr danach aus, dass er noch zustimmen wird.

Edbert (EvanE)

Neulich habe ich einen Tippfehler in einem Tag gefunden und habe über TagInfo nach ähnlichen Fehlern gesucht. Überraschenderweise habe ich dabei unter anderem eine Relation mit 0 Members erhalten!

Gibt es irgend eine Auswertung über Relationen ohne Members und Wege ohne Nodes? Wäre dass nicht eine Job für einen Bot, solche definitiv überflüssigen Objekte zu löschen? Es macht meiner Meinung nach wohl kaum Sinn in der History nachzuschauen, ob sich dort irgend ein Hinweis auf die frühere Position befindet.

mdk wrote:

Neulich habe ich einen Tippfehler in einem Tag gefunden und habe über TagInfo nach ähnlichen Fehlern gesucht. Überraschenderweise habe ich dabei unter anderem eine Relation mit 0 Members erhalten!

Gibt es irgend eine Auswertung über Relationen ohne Members und Wege ohne Nodes? Wäre dass nicht eine Job für einen Bot, solche definitiv überflüssigen Objekte zu löschen? Es macht meiner Meinung nach wohl kaum Sinn in der History nachzuschauen, ob sich dort irgend ein Hinweis auf die frühere Position befindet.

Eine ziemlich veraltete Liste gibt es hier: http://osm.lonvia.de/stuff/orphans.html
und der jüngste Vorschlag für einen Bot steht hier: http://lists.openstreetmap.org/pipermai … 62759.html
Einfach löschen wäre allerdings nicht so clever. Viele wurden nur versehentlich leergeräumt; dann macht es eventuell mehr Sinn, die letzte Version (soweit möglich) wiederherzustellen. Andererseits kann es auch bereits eine neue Relation geben, die den Platz der alten eingenommen hat. Alles nicht so einfach, und insofern nicht unbedingt eine gute Bot-Aufgabe.
Einigermaßen gefahrlos löschen könnte man allenfalls solche Relationen, die a) in Version 1 sind, b) selbst nicht durch andere Relationen referenziert werden und c) schon so alt sind, daß man davon ausgehen kann, daß der Ersteller nichts mehr damit vorhat. Darüber geben auch evtl. vorhandene Tags Auskunft.

Nach einem Blick auf den frisch aktualisierten OSMI: Hat da jetzt tatsächlich jemand rund um Bad Münstereifel aufgeräumt? Danke. Mir schien das aussichtslos.

Oli-Wan wrote:

Nach einem Blick auf den frisch aktualisierten OSMI: Hat da jetzt tatsächlich jemand rund um Bad Münstereifel aufgeräumt? Danke. Mir schien das aussichtslos.

Jaa, mir schien es auch aussichtslos... Nachdem ich letzten November ca. 1/3 dort irgendwo gemacht hab, hab ich kapituliert 🙂. Vor ein paar Tagen waren es nur noch 3 kleine Fehler.
Dank den Reperateuren ist es jetzt ein "Leichtes", NRW fehlerfrei zu bekommen/halten.

Oli-Wan wrote:

Nach einem Blick auf den frisch aktualisierten OSMI: Hat da jetzt tatsächlich jemand rund um Bad Münstereifel aufgeräumt? Danke. Mir schien das aussichtslos.

War das diese "hübsche" Ecke in der Eifel, die Lady Gaga M. kreiert hat? Da hab ich mich auch nicht mehr hingetraut.

Gruss
Walter

Hier ist massiv etwas kaputt gegegangen:
http://tools.geofabrik.de/osmi/debug.ht … icate_tags

Ich habe das Stück der fehlenden DE Grenze wieder in viele Relationen eingetragen, aber Salzburg Umgebung (86381) scheint total zerstört.
Wer kann helfen?
Ich kann auch den Verursacher oder das Changeset nicht finden, 86381 ist seit fast einem Jahr unverändert. http://www.openstreetmap.org/browse/relation/86381

fx99 wrote:

Ich kann auch den Verursacher oder das Changeset nicht finden, 86381 ist seit fast einem Jahr unverändert. http://www.openstreetmap.org/browse/relation/86381

Mein Tipp ist das hier: http://www.openstreetmap.org/browse/changeset/11514607 . Da hat vermutlich jemand nur die Grenzlinien geladen, aber nicht die zugehörigen Relationen.

Hat vermutlich nicht viel Sinn, wenn wir uns jetzt alle gleichzeitig darauf stürzen, das führt nur zu Konflikten. 86381 ist aber wieder geflickt. Alles nicht so schwierig, bloß viel Arbeit.

Edit: Na, ganz so viel ist es doch nicht. Da ist ein ziemlich dicker Hintergrund von schon vorher kaputten Multipolygonen.
86658, 87077, 86537, 86382 sind auch wieder repariert. Ich klinke mich erstmal aus.

Den Verursacher kann ich dir schon benennen: Das war ich. Nur was genau passiert ist und wie weiß ich noch nicht. Ich schau mal.

Edit: Ich habe jetzt 86.540 gefixed (Wals / Siezenheim)
86.657 ist auch erledigt (Elsbethen)

Habe jetzt gerade den Rest der MP bei mir am Rechner gefixed - warte nur noch bis Bayern runtergeladen ist, damit man das mal sortieren kann... (dann findet man in Zukunft auch die Fehler leichter...)

Final update: Morgen sollten alle MPs wieder passen...

Nachdem ja der OMSI-Inspector die MPs wieder "schöner" darstellt mal eine Frage:

Warum ist denn die das "Berchtesgadener Land" (Rel 62712) als type=boundary getagged und nicht als type=multipolygon? Hat es damit irgendweine Bewandtnis auf sich? (Und es betrifft ja nicht nur BGL - sind die meisten Regierungsbezirke...). Vielleicht kann mir da mal einer auf die Spürünge helfen...

tunnelbauer wrote:

Vielleicht kann mir da mal einer auf die Spürünge helfen...

ein wenig: http://forum.openstreetmap.org/viewtopic.php?id=16314

tl;dr: jemand hat bei uns viele Grenzen von type=multipolygon nach type=boundary umgetaggt.

Gruss
Walter

tunnelbauer wrote:

Nachdem ja der OMSI-Inspector die MPs wieder "schöner" darstellt mal eine Frage:

Warum ist denn die das "Berchtesgadener Land" (Rel 62712) als type=boundary getagged und nicht als type=multipolygon? Hat es damit irgendweine Bewandtnis auf sich? (Und es betrifft ja nicht nur BGL - sind die meisten Regierungsbezirke...). Vielleicht kann mir da mal einer auf die Spürünge helfen...

Man muss dazu wissen, dass der Entwickler des OSM-Inspektors type=boundary für Grenzen für falsch hält und stattdessen type=multipolygon bevorzugt. Deshalb wird type=boundary beim OSMI hervorgehoben.

Diese Ansicht wird nicht von allen geteilt, weder in Deutschland und schon gar nicht in der ganzen Welt.

Also Achtung:
Nicht alles was der OSMI anzeigt, muss auch als Fehler betrachtet werden.
(Das gilt auch für andere Ansichten des OSMI.)

Edbert (EvanE)

Blöd halt nur wenn sich der OSMI am wiki orientiert... (also der Entwickler eigentlich nicht schuld ist...)

http://wiki.openstreetmap.org/wiki/Relation:boundary

hurdygurdyman wrote:

Bei den touching inner besteht aber noch in Richtung Schwobe-Ländle gewisser Handlungsbedarf und da überschreite ich hin und wieder die Grenze und helfe aus.

Dir sei gesagt, dass touching inner rings keine Fehler sind. Es ist vielmehr ein Bug von OSMI, diese Prüfung überhaupt durchzuführen. Ich lege touching inner rings mit Absicht an (der Vorteil steht eh im Wiki) und muss mich immer wieder über Leute ärgern, die sie in blindem Vertrauen auf OSMI kaputtmachen.

Meiner Meinung nach gehört OSMI eingestellt, und dann erledigt sich auch die Frage nach der Koordination.

Wenn jemandem so fad ist, dass er unbedingt in fremden Daten herumkorrigieren will, dann soll er sich besser nach Keepright orientieren. Das stimmt zwar auch nicht in allen Belangen, ist aber wenigstens durchdacht, und man kann false positives markieren.

fkv wrote:

hurdygurdyman wrote:

Bei den touching inner besteht aber noch in Richtung Schwobe-Ländle gewisser Handlungsbedarf und da überschreite ich hin und wieder die Grenze und helfe aus.

Dir sei gesagt, dass touching inner rings keine Fehler sind. Es ist vielmehr ein Bug von OSMI, diese Prüfung überhaupt durchzuführen. Ich lege touching inner rings mit Absicht an (der Vorteil steht eh im Wiki) und muss mich immer wieder über Leute ärgern, die sie in blindem Vertrauen auf OSMI kaputtmachen.

Meiner Meinung nach gehört OSMI eingestellt, und dann erledigt sich auch die Frage nach der Koordination.

Wenn jemandem so fad ist, dass er unbedingt in fremden Daten herumkorrigieren will, dann soll er sich besser nach Keepright orientieren. Das stimmt zwar auch nicht in allen Belangen, ist aber wenigstens durchdacht, und man kann false positives markieren.

Nein, ich fange nicht schon wieder eine touching_inner-Diskussion an 😠 Dass in OSM Standards wie die simple features nicht gelten, mag ich auch nicht schon wieder durchkauen 🙁 Wo deren Vorteile sind vermag ich nicht zu erkennen 😉

Deine Sichtweise zu OSMI und keepright kann ich leider auch nicht uneingeschränkt teilen.

hurdygurdyman wrote:

Nein, ich fange nicht schon wieder eine touching_inner-Diskussion an 😠

Du hast sie schon in Beitrag #2 angefangen.

Dass in OSM Standards wie die simple features nicht gelten, mag ich auch nicht schon wieder durchkauen 🙁

Da gibt es nichts durchzukauen, die Spezifikation im Wiki ist eindeutig. Darum wundert mich um so mehr, dass du vorsätzlich an fremden Objekten herumpfuschst, die eh völlig korrekt sind.

fkv wrote:

Darum wundert mich um so mehr, dass du vorsätzlich an fremden Objekten herumpfuschst, die eh völlig korrekt sind.

Ich dachte die Daten in OSM gehören der Allgemeinheit. 🙄
Und wo steht, dass man touching_inner nicht vermeiden darf, wenn dies möglich ist? Wer entscheidet über Pfusch und Korrektheit?
Ich für meinen Teil halte MP's wie dieses http://tools.geofabrik.de/osmi/?view=mu … ,way_nodes für eine suboptimale Lösung, um es vornehm auszudrücken.

hurdygurdyman wrote:

Ich dachte die Daten in OSM gehören der Allgemeinheit. 🙄

Die Daten gehören dem jeweiligen Urheber. Er stellt sie nur der Allgemeinheit zur Verfügung.

Unter fremden Objekten verstehe ich solche, zu denen man selber nichts Inhaltliches beigetragen hat.

Und wo steht, dass man touching_inner nicht vermeiden darf, wenn dies möglich ist?

Wo steht, dass man überhaupt mappen muss? Was ist das für eine Frage?

Wer entscheidet über Pfusch und Korrektheit?

Im Zweifelsfall die Spezifikation im Wiki. Dazu ist es schließlich da.

Ich für meinen Teil halte MP's wie dieses http://tools.geofabrik.de/osmi/?view=mu … ,way_nodes für eine suboptimale Lösung, um es vornehm auszudrücken.

Da war ein Mikromapper aktiv. Das MP ist deshalb so wild, weil die Wege vom Farmland ausgespart und als Wiesen gemappt wurden. Ob das sinnvoll ist, darüber kann man streiten. Die Touching inner rings (152929874, 152929884) sind aber sehr wohl sinnvoll. Denn die Alternativen (zusätzlichen Way herum legen oder die beiden Flächen selber zu Mulipolygonen machen) wären westentlich komplizierter.

fkv wrote:

Die Daten gehören dem jeweiligen Urheber.

Quatsch. Es gibt keinerlei "Besitzrechte" an OSM-Daten.

wambacher wrote:

Quatsch. Es gibt keinerlei "Besitzrechte" an OSM-Daten.

Zitate aus dem deutschen Urheberrecht:

§ 15 Allgemeines
(1) Der Urheber hat das ausschließliche Recht, sein Werk in körperlicher Form zu verwerten; das Recht umfaßt insbesondere
1. das Vervielfältigungsrecht (§ 16),
2. das Verbreitungsrecht (§ 17),
3. das Ausstellungsrecht (§ 18).

(2) Der Urheber hat ferner das ausschließliche Recht, sein Werk in unkörperlicher Form öffentlich wiederzugeben (Recht der öffentlichen Wiedergabe). Das Recht der öffentlichen Wiedergabe umfasst insbesondere
1. das Vortrags-, Aufführungs- und Vorführungsrecht (§ 19),
2. das Recht der öffentlichen Zugänglichmachung (§ 19a),
3. das Senderecht (§ 20),
4. das Recht der Wiedergabe durch Bild- oder Tonträger (§ 21),
5. das Recht der Wiedergabe von Funksendungen und von öffentlicher Zugänglichmachung (§ 22).

§ 29 Rechtsgeschäfte über das Urheberrecht
(1) Das Urheberrecht ist nicht übertragbar, es sei denn, es wird in Erfüllung einer Verfügung von Todes wegen oder an Miterben im Wege der Erbauseinandersetzung übertragen.

Und im konkreten Fall besonders interessant:
§ 14 Entstellung des Werkes
Der Urheber hat das Recht, eine Entstellung oder eine andere Beeinträchtigung seines Werkes zu verbieten, die geeignet ist, seine berechtigten geistigen oder persönlichen Interessen am Werk zu gefährden.

Zu touching inner:
http://forum.openstreetmap.org/viewtopic.php?id=13669

Zum Urheberrecht:
Ich ändere nicht die vom Urheber eingebrachten Informationen, sondern deren Zuordnung. Die closed ways der touching_inner bleiben erhalten und werden von mir lediglich aus dem MP als inner entfernt. Unter Verwendung der nodes, welche auf der gemeinsamen Außenlinie der Innenflächen liegen, ziehe ich einen closed way, den ich ohne Flächeneigenschaft in das MP als inner einbinde. Darin sehe ich keine Entstellung des Werkes.

Und alle die simple features schätzen und professionell verwenden, sind zufrieden.

hurdygurdyman wrote:

ziehe ich einen closed way, den ich ohne Flächeneigenschaft in das MP als inner einbinde. Darin sehe ich keine Entstellung des Werkes.

Doch, du fügst ein überflüssiges Objekt ein, das die Datenbank aufbläht und die Wartung erschwert (z.B. beim Einfügen neuer Nodes, längere Objektlisten).

Und alle die simple features schätzen und professionell verwenden, sind zufrieden.

Es gibt in OSM keine "simple features"! Um die verwenden zu können, muss man die Daten konvertieren. Deine Manipulationen an einzelnen Datensätzen ändern daran überhaupt nichts.

es ist schon toll, dass manche der ODbL zugestimmt haben und immer noch nicht begriffen haben, was das bedeutet.

@fkv: Jeder bei OSM hat die Daten, die er beigesteuert hat derzeit unter cc-by-sa lizenziert. Das bedeutet, er hat jedem das Recht zugesprochen, diese Daten zu bearbeiten, und zu nutzen, wenn er diese unter den gleichen Bedingungen wieder veröffentlicht.

Die "original"-Daten die du bspw. im josm gezeichnet hast sind das Werk was du geschaffen hast. Da bist du dran Urheber und kannst bestimmen, was damit geschieht. Mit dem hochladen hast du der OSMF die Erlaubnis erteilt diese unter cc-by-sa zu verteilen (siehe oben). Wenn du dann das "original" löschen solltest, ist das dann dein privates Pech.

Ich schlage vor, dass wir uns wieder dem eigentlichen Thema zuwenden. Es geht um die Koordination von Multipolygon-Reparaturen.

aighes wrote:

@fkv: Jeder bei OSM hat die Daten, die er beigesteuert hat derzeit unter cc-by-sa lizenziert. Das bedeutet, er hat jedem das Recht zugesprochen, diese Daten zu bearbeiten, und zu nutzen, wenn er diese unter den gleichen Bedingungen wieder veröffentlicht.

Das ändert nichts daran, dass man deren Urheber ist und die zitierten Gesetzestexte volle Gültigkeit haben. 2 User hier verwechseln Eigentum mit Nutzungsrecht.

Aber ich wollte gar keine Paragrafenreiterei anfangen. Es sollte eine Sache des Anstandes sein, nicht die Werke eines anderen zu verunstalten. Vor so strittigen Änderungen sollte man zumindest den ursprünglichen Mapper oder den vorigen Bearbeiter kontaktieren. Soviel zum Thema Koordination...