seid gestern abend diskutieren wir im talk-de uber unsern alten “freund”.
siehe “trunk_link → trunk im großen stile - etc.” (etwas weiter hinten)
Diesmal hat er im rhein-main-gebiet ca 550 radwege (15500 nodes) in 2 bulk-loads hochgeladen.
Die wege liegen “voellig daneben”, gehen quer über straßen und andere ways; sind auch dort, wo bereits radwege vorhanden waren und sind zuletzt auch noch falsch getaggt.
anfragen an ihn sind aufgrund längerer erfahrungen zwecklos.
gruss
wambacher
p.s. die quelle der daten ist natürlich voellig unklar - aber ich würd nen besen fressen, wenn da nicht eine radfahrer-cd geknackt wurde.
koennte das mal jemand ueberprüfen? ich hab sowas nicht.
hast Du rund 500 Radwege hochgeladen, die offenbar in keinem
Zusammenhang mit bereits existierenden Daten stehen. Die Wege
überkreuzen sich wild mit existierenden Strassen, verdoppeln zum Teil
sogar von Dir selbst früher hochgeladene Radwege.
Diese Daten sind nicht sinnvoll. Ist Dir da ein Fehler unterlaufen?
Kannst Du das selber wieder reparieren, oder brauchst Du Hilfe dabei?
Beim Vergleich der beiden wird aus dem create ein delete, aus dem visible=“true” ein visible="false"und die Versionsnummer um eins erhöht
Bei der way id fällt bei Delete noch mehr weg.
a.
Falls ein REVERT nicht funktioniert, könnte man nicht ein “falsch” angelegtes Changeset runterladen und per Script die Creates etc. in Deletes “umkehren” und das dann als neues Changeset wiedereinspielen?
b.
Was passiert, wenn eine ID zwar vorhanden, aber verschoben wurde?
Würde es ev. sogar reichen, nur die ID zu löschen und ein visible=“false” zu setzen?
Vielleicht hab ich´s noch nicht ganz verstanden:
Inzwischen habe ich auch eine Änderung getestet. Bei der Änderung einer ID wird aus dem “Create” ein “Modify”.
Modify würde bei der Rückgängigmachung (Erstellung per Script) natürlich übersprungen, weil ja nur das “Create” zum “Delete” geändert würde.
Dazu zwei Beispiele:
Beispiel 1 (nach einem Modify) wird nicht gelöscht
dann:
node id=“761932846” und visible=“true” sind gleichgeblieben, aber lat=“52.1060104” lon=“7.3769909” wurden geändert.
Beispiel 2 (ohne Modify, bzw. niemand ändert den Node)
dann:
Wie man sieht, sind node id=“761991318” lat=“52.1060104” lon=“7.3769909” gleich geblieben, aber visible=“true” wurde zu visible=“false” .
Wenn man id=“761991318”, lat=“52.1060104” und lon=“7.3769909” noch per Script prüfen würde, kann man m. E. nichts löschen was inzwischen geändert (Modify im Beispiel 1) wurde.
Oder meinst Du, daß eine node id NUMMER nach dem Löschen und nach Neuanlage von irgendwas nochmal vergeben wird? Das kann ich mir bei einer Datenbank eigentlich nicht vorstellen.
Wenn man das ausführt:
wird dann nur gelöscht, wenn die node id genauso mit ihren Attributen auch vorhanden ist, oder wird die node id immer gelöscht, egal wo sie sich inzwischen befindet oder ob die Eigenschaften sich geändert haben?
Ein revert ist kein Problem solange ein Object nach dem changeset das zurückgesetzt werden soll ncht mehr verändert wurde. Nach einer Änderung ist das für ein Script nicht mehr automatisch lösbar ohne Datenverlust zu riskieren.
Das revert script macht nichts anderes, es packt nur Objekte an die nicht geändert wurden.
Erst mal hallo zusammen (mein erster Eintrag im Forum).
Zu der Oberförster Thematik hätte ich einige Fragen:
Gibt es die Möglichkeit in JOSM sämtliche Daten eines Changesets zu laden (inklusive gelöschter), das würde das manuelle Aufräumen erheblich vereinfachen?
Sollten die neuen Wege komplett gelöscht werden, oder können sie auch (nach Überprüfung) eingepflegt werden? (Gerade in Hinblick auf die unklare Quelle der Daten bin ich mir hier unsicher).
Heute hat er in Idar-Oberstein bei der B41 (u.a. way 123093166) zum zweiten Mal aus ref=“B 41” ein ref=“B 41 Rad-u. Mofaverbot” gemacht und eine highway=residential zusätzlich mit motorroad=yes versehen (Way 23345511)
highway=path,foot=designated,bicycle=designated
ok aber dann
layer=1 ?? und oneway=yes !!! bei nem fußweg
wartet mal den nächsten bulk-load ab, dann kommt mal wieder richtig freude auf.