JOSM entfernt automatisch created_by=......

surveyor54 · 2018-01-18T18:06:23.000Z

Ich weiß nicht ob es schon jemanden aufgefallen ist?
JOSM entfernt automatisch created_by=…

In JOSM ohne etwas gemacht zu haben.

Nach dem Hochladen, habe es nicht gelöscht.

Gruß
svr54

Prince_Kassad · 2018-01-18T18:08:54.000Z

Ist schon ewig so, soweit ich weiß wurde das kurz nach Einführung der API 0.6 eingeführt (wann war das nochmal…) created_by soll nur noch als Changeset-Tag verwendet werden, an Objekten in der Datenbank ist created_by unerwünscht und darf von jedem gelöscht werden.

gormo · 2018-01-18T22:00:02.000Z

Prince Kassad:

Ist schon ewig so, soweit ich weiß wurde das kurz nach Einführung der API 0.6 eingeführt (wann war das nochmal…) created_by soll nur noch als Changeset-Tag verwendet werden, an Objekten in der Datenbank ist created_by unerwünscht und darf von jedem gelöscht werden.

Jo, siehe https://wiki.openstreetmap.org/wiki/DE:Key:created_by . Ist Seit September 2009 so.

Tordanik · 2018-01-18T23:05:36.000Z

Ist übrigens nicht das einzige automatisch entfernte Tag, ein klein wenig Info zum Thema im Wiki unter dem Stichwort “Discardable tags” zu finden. Dort ist auch im JOSM-Sourcecode die entsprechende Stelle verlinkt. Aktuell entfernt JOSM also automatisch:

"created_by",
"converted_by",
"geobase:datasetName",
"geobase:uuid",
"KSJ2:ADS",
"KSJ2:ARE",
"KSJ2:AdminArea",
"KSJ2:COP_label",
"KSJ2:DFD",
"KSJ2:INT",
"KSJ2:INT_label",
"KSJ2:LOC",
"KSJ2:LPN",
"KSJ2:OPC",
"KSJ2:PubFacAdmin",
"KSJ2:RAC",
"KSJ2:RAC_label",
"KSJ2:RIC",
"KSJ2:RIN",
"KSJ2:WSC",
"KSJ2:coordinate",
"KSJ2:curve_id",
"KSJ2:curve_type",
"KSJ2:filename",
"KSJ2:lake_id",
"KSJ2:lat",
"KSJ2:long",
"KSJ2:river_id",
"odbl",
"odbl:note",
"SK53_bulk:load",
"sub_sea:type",
"tiger:source",
"tiger:separated",
"tiger:tlid",
"tiger:upload_uuid",
"yh:LINE_NAME",
"yh:LINE_NUM",
"yh:STRUCTURE",
"yh:TOTYUMONO",
"yh:TYPE",
"yh:WIDTH",
"yh:WIDTH_RANK"

woodpeck · 2018-01-19T09:12:20.000Z

Tordanik:

Ist übrigens nicht das einzige automatisch entfernte Tag,

Und bevor irgendjemand fragt: Nein, wir wollen kein Skript laufen lassen, das die alle in einem Rutsch entfernt

Die Methode “wir killen diese Tags, wenn jemand das Objekt sowieso mal anfasst” ist in fast jeder Hinsicht besser. Sie vermeidet die Illusion von Aktualiät (“wow, in dieser Gegend gibt es nichts, was seit mehr als 2 Jahren unverändert ist” - “ja, weil vor 2 Jahren das created_by überall entfernt wurde”) und spart auch Platz in der zentralen Datenbank, da dort für jede Version eine komplette Kopie des Objekts gehalten wird, so dass das Löschen von created_by unnötig eine weitere Kopie des kompletten Objekts bedeutet.

Bye
Frederik

SimonPoole · 2018-01-19T09:52:04.000Z

Und die entsprechende Liste von iD und vespucci: https://github.com/openstreetmap/iD/blob/master/data/discarded.json

Polyglot · 2018-01-19T10:43:18.000Z

Wenn das wirklich ein Problem ist, kannst du das hier ändern:

JOSM Advanced preferences
tags.discardable

Ist aber eigentlich gut so.

Jo

Harald_Hartmann · 2018-01-19T11:17:15.000Z

woodpeck:

Die Methode “wir killen diese Tags, wenn jemand das Objekt sowieso mal anfasst” ist in fast jeder Hinsicht besser. Sie vermeidet die Illusion von Aktualiät (“wow, in dieser Gegend gibt es nichts, was seit mehr als 2 Jahren unverändert ist” - “ja, weil vor 2 Jahren das created_by überall entfernt wurde”) und spart auch Platz in der zentralen Datenbank, da dort für jede Version eine komplette Kopie des Objekts gehalten wird, so dass das Löschen von created_by unnötig eine weitere Kopie des kompletten Objekts bedeutet.

… ja, schade dass damals keiner daran gedacht hatte die Versionsinformationen an jedem einzelnen verdammten KeyValuePaar zu halten

mmd · 2018-01-19T11:30:34.000Z

Harald Hartmann:

ja, schade dass damals keiner daran gedacht hatte die Versionsinformationen an jedem einzelnen verdammten KeyValuePaar zu halten

Nö, das ist heute schon so. In der Historie wird jedes Tag mit Object Id, Version, Key und Value gespeichert:
https://git.openstreetmap.org/rails.git/blob/HEAD:/db/structure.sql#l740

Um dort wirklich Platz zu sparen, müsste man sich merken, welche Tags im Vergleich zur Vorgängerversion dazugekommen bzw. weggefallen sind (Overpass API macht das so). Dann ist aber der Zugriff auf eine einzelne Version teurer, weil man die Historie durchnudeln muss.

Harald_Hartmann · 2018-01-19T14:28:30.000Z

Mit Versioninformationen meinte ich alle Informationen zu dieser Version des jeweiligen Key Value Paares, also v.a. auch das Datum der Änderung … sprich ich wollte das Thema Logging auf Attributebene und nicht auf (gesamter) Objektebene ansprechen.
Ich stelle jetzt einfach mal die Frage: Bearbeite ich wirklich ein Objekt, oder ändere ich in diesem Objekt einfach nur ein paar Attribute? Das Problem geht ja noch weiter, dass häufig Mapper vertächtigt werden irgendwas schlimmes gemacht zu haben, nur weil sie als letzter Bearbeiter in der Historie eines Objektes stehen, aber den vertächtigen/schlimmen Wert selbst gar nicht eingetragen haben …

mmd · 2018-01-19T17:31:56.000Z

Harald Hartmann:

Bearbeite ich wirklich ein Objekt, oder ändere ich in diesem Objekt einfach nur ein paar Attribute?

Gut, für die Aufgabe gibt’s ja genügend Tools, Achavi, OSM History Viewer, etc. lässt sich also alles problemlos aus den Daten ermitteln, ohne jetzt groß irgendwas zu ändern. Es gibt sogar ein Issue, die Änderungen farbig zu markieren, also auf Tag-Ebene. Leider hat sich noch niemand breit schlagen lassen, sowas zu implementieren:

https://github.com/openstreetmap/openstreetmap-website/issues/738

Harald_Hartmann · 2018-01-19T17:40:47.000Z

@mmd: Meine Reise sollte dorthingehen, das Argument von woodpeck - was ja aktuell trotzdem seine Gültigkeit hat - zu entkräften und es auf Attributebene sehr wohl möglich zu machen, einfach ein paar alte obsolete Keys automatisiert loszuwerden.

mmd · 2018-01-19T17:46:55.000Z

Hmm… deine Idee wäre dann, die Tags einzeln zu versionieren, d.h. nur wenn ein Tag Value sich ändert wird eine neue Tag-Version gezogen? Soll dann eine weitere Tabelle den Bezug zwischen (Node Id + Version) und (Tag + Version) herstellen? Ein reiner Zeitvergleich funzt ja nicht, soll ja vorkommen , dass in einer Sekunde mehrere Versionen eines Nodes erzeugt wurden.

Harald_Hartmann · 2018-01-19T17:57:56.000Z

Zur Not auch das … aber wenn sich mehrere Tags eines OSM Objekts ändern, dann wäre das ein abgeschlossenes Changesets, also Changeset nicht im Sinne von OSM sondern im Sinne eines Commits eines Versionkontrollsystems, d.h. die Version des Objekts ändert sich nur einmal.