das ist einfach. Ich habe Ihnen keine Erlaubnis erteilt Zitate aus meiner privaten Nachricht an Sie zu veröffentlichen. Sie haben mich ja oben stehend immerhin richtig zitiert, bitte lesen Sie den Satz und verstehen Sie den Zusammenhang. Und jezt fordere ich Sie nochmals auf die widerrechtliche Zitierung aus meiner Nachricht an Sie zu löschen, denn das ist Unrecht.
Im Übrigen haben Sie aus gutem Grund darauf verzichtet Ihre gesamte Nachricht an mich zu veröffentlichen, aber Sie haben nur einen Auszug aus meiner privaten Antwort auf Ihre Nachricht - widerrechtlich - zitiert um mich so zu diskreditieren.
Die Stufen habe ich nicht vorsätzlich gelöscht. Ich habe zu dem Zeitpunkt mtb tags wiederhergestellt. Dabei habe ich auch grundlos fragmentierte Wegstücke zusammengesetzt, vermutlich sind dabei die Stufen leider! verloren gegangen.
Ich habe keinesfalls vorsätzlich Informationen außer bycicle=no auf Pfaden gelöscht. Es ist die Unwahrheit zu suggerieren ich hätte in großem Stil wichtige Informationen gelöscht. Ich habe an dem Tag an dem ich die edits gemacht habe auf einer Wegstrecke von ca. 110km mtb tags wieder eingetragen, um wenigstens ansatzweise die von Ihnen über vermutlich mehr als ein halbes Jahr auf großen Teilen der schwäbischen Alb vorsätzlich gelöschten mtb tags, wieder herzustellen. Da Sie die Wegstücke in zum Teil kürzeste Fragmente, oft ohne Grund, unterteilt haben musste ich tausende dieser Kleinstfragmente Stück für Stück editieren. Dabei können Fehler passieren. Die haben Sie recherchiert. Und mit damit versuchen Sie mich zu diskreditieren. Dabei stehen die leider! verlorengenangen Informationen durch meine Bearbeitung in keinem Verhältnis zu dem was ich wiederhergestellt habe. Was Sie hier nicht an die große Glocke hängen; Sie haben umgehend meine gesamten mtb tags von eben diesem Zeitraum sofort wieder vorsätzlich gelöscht trotz der hier bereits laufenden und von Ihnen gestarteten Diskussion, und obwohl bereits deutlich wurde das mtb tags nicht gelöscht werden sollten, und trotdem ich Sie vorab in einer privaten Nachricht gebeten habe das nicht zu tun weil es entgegen der osm Richtlinien ist.
Die Argumente mögen soweit richtig sein, mir geht es aber um das Arbeiten auf openstreetmap. Durch die Fragmentierung wird es sehr aufwendig einen Wegverlauf zu taggen weil ja jedes Fragment einzeln angefasst werden muss. Das ist was stört und weshalb ich fordere nur zu fragmentieren wo auch konkret notwendig und nicht vorbeugend wie Sie! Beim mühevollen in Zusammensetzen unnötig von Ihnen fragmentierter Wegstücke in Kleinstarbeit können Fehler passieren, so ging es mir. Was von Ihnen wiederum ausgeschlachtet wird. Schizophren.
was ist denn da die Ursache. Wo ich beklage das alle Historie vor Wychuchols Eingriff abhanden gekommen ist und der sich aber dafür verbürgt das nicht getan zu haben, muss es doch einen anderen Grund geben. Es ist mir eben auf wirklich vielen Wegen die Wychuchol editiert hat aufgefallen deren Verlauf sicher nicht korrigiert werden musste und es sind auch eine Menge Wege. Beispiele habe ich hochgeladen. Warum verschwindet jegliche Verssionshistorie vor seinem Eingriff, ist das ein bug des id-Editor mit dem Wychuchol laut eigenen Angaben arbeitet, oder bestätigt das eher die Beiträge #111 - #113?
Erstmal danke. Ich glaube mich zu erinnern das für 5-6 sogenannte Spotter notwendig sind um nicht zu verunglücken. Solche Wege sind mir auf der schwäbischen Alb nicht bekannt bzw. klassifiziere ich nicht.
Vielleicht weißt Du bitte wo ich eine Anleitung finden kann wie das plugin für josm bedient wird? Mann kann sich offenbar die Daten nach josm auf eine separate Ebene laden um etwas komfortabler arbeiten zu können.
Der Bereich mit gelöschten mtb tags ist ca. 550 Quadratkilometer groß. Ich möchte das gerne in josm bearbeiten können um den Überblick zu haben.
Die Versionshistorie eines Objektes verschwindet nie. Das ist technisch nicht vorgesehen und somit auch nicht möglich. Kein Programm, also auch nicht iD, kann die History “löschen”. Nie und nimmer.
Aber:
wenn ein Objekt gelöscht und danach neu eingetragen wird, ist die History weg und das neue Objekt bekommt eine neue OSM-ID und die Version 1
wenn ein Objekt “geteilt” wird (z.B. highway wird in 2 Teile aufgebrochen), dann wird für eines der Teile ein neues “unbelastetes” Objekt angelegt. Welches der beiden das ist, ist zufällig.
Gerade die 2. Möglichkeit verwirrt den unaufmerksamen Mapper schon sehr, da man das oft erst auf den 2. Blick erkennt.
Gruss
walter
ps: ansonsten ist es absolut unüblich jemanden bei OSM zu siezen. Wir sind eine Community und da braucht man das nicht. Zudem halte ich diese Diskussion mit Mailzitaten und Schuldzuweisungen, Vorwürfen und Richtigstellungen für absolut unnötig, wenn nicht sogar störend.
Das so etwas nicht völlig abwegig ist, zeigt z.B. folgender aktueller Fall, auch wenn dieser nicht ganz so dramatisch ist: http://www.rheinpfalz.de/nachrichten/titelseite/artikel/sieben-maennlein-stehn-im-walde/
Zwei Familien verirren sich im Wald, die Kinder sind erschöpft, es ist eiskalt, an einem Rettungspunkt rufen diese die Polizei.
Querliegende Bäume (Forstarbeiten) versperren die Wege, weshalb die Polizei zunächst den Rettungspunkt nicht erreichen kann, deshalb fährt ein Mountainbiker über einen Singletrail in nur 15 Minuten zu dem Rettungspunkt und versorgt die Verirrten mit Essen.
Danach dauert es nochmals mehr als eine Stunde bis die Polizei den Rettungspunkt erreicht um die Familien aus dem Wald zu bringen.
Also könnten die MTB-Tags auch bei verbotenen Singletrails für Retter nützlich sein.
Bei JOSM wäre das nicht zufällig, dort behält immer der Anfang des Weges die alte ID.
Ich kehre sogar manchmal die Wegrichtung vor der Teilung um, damit der richtige Teil die alte ID behält (und ändere die Richtung dann wieder zurück).
Ich möchte mich nicht von jemandem dutzen lassen der mich bei seiner Erstkontaktaufnahme mit mir in seiner Nachricht unhöflich, oberlehrerhaft und an der Grenze zur Beleidigung angeschrieben hat. Auch vor dem Hintergrund dessen Fehlverhaltens im Vorfeld und sehr später Einsicht nur unter vielfacher Nachfrage / Druck anderer. Danke für das Verständnis.
Auch das spricht gegen eine grundlose Fragmentierung von bestehenden Wegen ohne dass eine Notwendigkeit dafür bestünde, wie ich es auch aus anderen Gründen fordere. Das scheint außer mir aber ebenfalls keinen zu stören.
Ich glaube es ist möglich in josm einen Eltern-Vektor zuerst durch Zugabe von weiteren Punkten in mehrere Kinder-Vektoren zu teilen so dass alle Informationen des Eltern-Vektors auf den Kinder-Vektoren vorhanden sein müssten. Dann wäre das Aufteilen unter Verlust der Versionshistorie gar nicht nötig.
Das ist das Plugin: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/mirrored_download
Damit kannst du dann über “Datei → Mittels Overpass-API laden” die Daten von der Overpass-API laden.
Einfach die entsprechende Abfrage in das Feld “Overpass-Abfrage” eingeben, z.B.:
[date:"2014-08-01T15:00:00Z"];
way
["mtb:scale"="0"];
(._;>;);
out meta;
Datum, mtb:scale, … kannst du entsprechend anpassen, evtl. reichen dir auch die “path”, dann [“highway”=“path”] hinzufügen:
[date:"2014-08-01T15:00:00Z"];
way
["highway"="path"]
["mtb:scale"="0"];
(._;>;);
out meta;
Das sollte funktionieren, nur wie gesagt nicht versuchen diese Ebene hochzuladen.
Das sind schon sehr konstruirte Beispiele / seltene Ausnahmefälle. Ich denke man sollte es halten wie extremcarver argumentiert, es brauch keine Rechtfertigung für die mtb tags, es ist eine Zustandsbeschreibung bzw. Tauglichkeitsbeschreibung. Allein dies kollidiert mit keinem Gesetz, die sich auch wieder ändern können. Klassifizierungen die für sich selbst nicht ungesetzlich sind und auch osm Richtlinien entsprechen dürfen getagt werden.
Danke erstmal, ich würde diese Ebene mit den Daten aus der Abfrage als Maske benutzen mit der ich dann die eigentliche Datenebene belichte sozusagen. Wird schon schiefgehen.
Wenn Du dir die Daten von einem bestimmten Tag runterlädst, dann ist der komplette Weg da. Du kannst dann durch die Versionshistorie lesen, was andere Leute nach dem gewählten Tag gemacht haben.
Ich habe das gerade mit bicycle=yes und highway=yes gemacht.
Dann müsste man die Daten von heute runterladen.
Der alte Track lässt dich erkennen, wo geschnippelt worden ist und du überträgst dann die entsprechenden Werte auf die neuen Teilabschnitte.
Was ich nicht herausgefunden habe, wie man zwei Datenebnen in JOSM anlegen kann. Das wäre praktisch.
Was noch praktischer wäre, was möglich sein muss, aber ich nicht von der Syntay hinbekommen habe, Änderungen eines User zu einem bestimmten Tag zu finden.
Also Wychuchol war nur an einigen Tagen mit hochladen tätig.
Also die Wege suchen, die Wychuchol an diesen Tagen geändert hat, an denen keine MTB-Tags vorhanden sind.
Dann alle Wege am Tag davor suchen, die einen MTB-Tag haben. Und entsprechend abarbeiten.
Bei meinen Versuchen habe ich festgestellt, dass bei einer Stichprobe von 20 bicycle=yes die Hälfte von Wychuchol gelöscht wurden. Ein umstellen auf no würde ich verstehen, aber löschen und dann teilweise monatelang nicht behandeln, geht nicht.
Leider kann man auch sehen, dass du seine access-Tags gnadenlos gelöscht hast. Ihr beide nehmt euch nichts.
a) Oben links Datei/Neue Ebene erzeugt eine leere Ebene
b) Beim Laden von Daten (grüner Pfeil) links unten Als neue Ebene laden anklicken. Achtung: ab dann wird für jedes “Nachladen” einen neue Ebene angelegt! Also lieber bald zurücksetzten.
Und wenn es doch passiert ist: Bearbeiten/Ebene vereinigen fixt das dann.
c) An anderen Stellen wie z.B. Datei/Objekt herunterladen steht schon mal Separate Ebene oder ähnliches.
Gruss
walter
PS: Umschalten kann man dann oben rechts im Ebenen-Menu. Muttu mal ein wenig klimpern.
Ich denke auch die ganzen konstruierten Exrem- und Ausnahmefälle tragen nichts zur Diskussion bei. Gemappt und auf Karten dargestellt wird der Normalfall.
In Notsituationen mit Gefahr für Leib- und Leben dürfen Befahr- oder Betretungsverbote sowieso ignoriert, Querfeldein gefahren und geritten, Sachen aufgebrochen und beschädigt werden, um zum Verünglückten zu gelangen und Hilfe zu leisten. Da ist es absolut völlig egal was irgendjemand gemappt hat.
