Ohne das in irgendeiner Form rechtfertigen zu wollen: Da ging es mir mehr um das Überprüfen und Herunterladen einer Versionshistorie (bspw. welcher User hat jetzt wann welches Tag gesetzt, wann wurde welches Tag zuletzt geändert) statt um den verbrauchten Speicherplatz.
Versuch dann mal, bei einem Objekt mit ~200 Versionen die History im Browser zu laden und vor allem, da noch durchzublicken - keine Chance.
Da müssen wir uns echt was ausdenken, unabhängig von SC. Sonst fliegt uns das irgendwann um die Ohren.
Die History von Relationen kann man - auch, wenn das nichts mit SC zu tun hat - jetzt teilweise schon kaum mehr überblicken. Wenn ich z. B. bei einer PTV2-Relation überprüfen möchte, wann ein bestimmtes Straßensegment hinzugefügt oder herausgenommen wurde. Wie macht ihr so was? Die History-Anzeige von JOSM kenne ich, aber irgendwie finde ich die recht unübersichtlich (gerade bei den Relationen)…
Genau das ist der Punkt. Es geht darum, dass es technisch anders / besser gelöst werden muss. Damit ist es aber als Argument gegen Dinge wieder hinfällig.
Wenn ich da an git denke, womit noch deutlich komplexere Dinge abgebildet werden ist klar, dass es entsprechende Möglichkeiten zur Umsetzung gibt. Nur hat das mit dem aktuellen Thema nichts zu tun.
Yes. Maybe not in the same table in that database, though - you are correct it would be preferable alongside other metainformation (e.g. like user of last edit, or history at all. It’s not useless information, but I agree with you that it is metainformation). But it needs to be accessible and atomically (auto-)updatable with that same API to that same database.
But until something like that is implemented, however, such metadata things like check_date, note, fixme, various ref:* links, source:*, lifecycle prefix tags like removed: etc. tags will likely continue to live in main tags table, as people find them useful for mapping
(I’ve suggested some ways to hide them in previous post, if one really dislikes seeing them - JOSM only though. But iD doesn’t show such tags by default anyway)
Those extra tags are not damaging data you care about. They are not reducing value of OSM for you, and are increasing it for others. And it is ignorable if one so chooses. So, if all that is the case, it would be nice if people wouldn’t try to enforce their preferences on others (neither one side forcing other to stop using check_date:* and its advantages, nor the other side forcing them that they must use check_date:* for all their edits)
So some people may use check_date:* all the time, and other may decide never to use check_date:*, or anything in between – and they can still all live and map happily together (even while having such minor and benign differences in opinion!)
That is true, but existence and location/geometry are likely to be reviewed at the time of survey. I map a lot of Node-Network nodes and routes; besides existence and location/geometry survey:date also applies to the Node label (name, code or number) and the refs of the Nodes and the Routes. No guarantees, though.
It would be worth a lot if each tag change were automatically date-stamped at the database level, and it could be made available in JOSM and other tools. Adding separate date:attribute tags is not the best method, though it can help out with particular workflows aimed at particular attributes.
You are right! You just can’t view it by tag/key, only by object-version. So you have to walk through the object versions to find a particular tag change.
But it’s a per-tag verification date that’s wanted, even when there is no change, and you can’t stamp that automatically.
The assumption is, I think, that changing something in the object means the mapper verified and corrected all the tags and the geometry; which very often is not the case.
Still, since verification and updating is vital to the database, a basic function to record just that would be an asset.
Also ich habe hier ein Radroutensystem, da sind einige Routen in OSM so eingetragen, wie sie in Wirklichkeit verlaufen und andere Routen sind seit Jahren falsch eingetragen. Dass weiß ich, weil ich sie abgefahren bin. Ich bin einige Routen abgefahren, weil in den 31 Routen ca. 1500 km, nirgendwo steht, wann der Verlauf zum letzten Mal überprüft worden ist.
Schön! Ich bin seit letztem Herbst auch ein paar tausend km geradelt und habe dabei einen Haufen Radrouten dokumentiert. Aus meiner Sicht ist das das tolle an OSM: Man kann immer noch mal losfahren und schauen, ob sich was geändert hat oder vielleicht, weil man jetzt doch noch die Straßengräben anschaut oder was auch immer.
Ist bei mir genau so. Hier hat der Landkreis vor einiger Zeit eine neue Radwegweisung ausgerollt, bei der alte Wegweiser teilweise unverändert übernommen wurden. Wenn ich an diesen nicht check_date setzen würde, dann müsste ich eine Tabelle mit den bereits überprüften Wegweisern führen, von der dann aber nur ich etwas hätte. Andere Mapper, die zur Aktualität der OSM-Daten beitragen wollen, müssten nochmal vor Ort fahren. Ein Mapper, der zufällig an einem solchen Wegweiser vorbei kommt, hätte keine Möglichkeit mich (und alle anderen) darüber zu informieren. Meine Vorstellung von der Zusammenarbeit in einer Community ist das nicht
In meiner Gegend war praktisch kein Wegweiser oder Marker erfasst und die meisten Routen fehlten auch oder waren teils falsch. Ich habe also mehr als 250 Wegweiser und noch viel mehr Marker neu erfasst. Möglicherweise streiten/sorgen sich in anderen Gegenden ja viele Mapper um die gleiche Gegend, hier eher nicht, manche Gebiete wurden seit 10 Jahren nicht mehr nennenswert geändert oder sind gar noch ganz leer.
Da, wo ich Aktivitäten von anderen Mappern wahrnehme, da schreibe ich CS-Kommentare. Das ist meine Vorstellung von Zusammenarbeit.
Nachtrag: Ich mappe freiwillig und aus Spaß an der Freud. Ich wundere und freue mich, wenn ich tatsächlich mal eine Straße in OSM so vorfinde, wie ich sie selbst gemappt hätte. Gibt es denn wirklich Gegenden, in denen es schwer ist, was “neues” zu finden und man daher frustriert nach Hause kommt und nichts zu mappen hat? Das Problem sehe ich in meiner Heimat nicht mal in 20 Jahren.
Es geht hier doch um diese Situation: Ein Objekt vom Typ t (z.B. Briefkasten, Hundekottütenspender,…) wurde zuletzt vor x Jahren geändert. Du kommst auf Mappingtour an diesem Objekt vorbei, notierst dir die Eigenschaften des Objekts (oder machst ein Foto, oder…). Zu Hause im Editor siehst du, dass das Objekt bereits korrekt in OSM erfasst ist. Dann wäre es nützlich, wenn du diese Information in der DB hinterlegen würdest. Warum? Wenn ein anderer Mapper in deiner Gegend beschließt, alle Objekte vom Typ t in seiner Umgebung zu überprüfen, die seit x Jahren nicht mehr angefasst oder überprüft wurden, dann fällt darunter auch das von dir in der Zwischenzeit geprüfte Objekt und er fährt hin. Mit einem check_date von dir, hätte er sich die Fahrt sparen können.
Wie du das mit einem CS-Kommentar machen willst, ist mir nicht klar.
Sofern der/diejenige mit dem Rad oder zu Fuss unterwegs ist, sehe ich überhaupt kein Problem. Wenn jemand aber mit einem Kfz auf Reisen geht, nur um OSM Daten zu sammeln, dann ist das evtl, strafbar, mindestens aber doch sehr fragwürdig.
Du solltest nicht immer nur von dir ausgehen. Ich versuche die Radwegweisung eines Landkreises in OSM zu erfassen und aktuell zu halten. Außer mir macht das in diesem Bereich sonst niemand systematisch. Die Wegweiser sind oft 25km und mehr weg, hügelig ist es auch. Da bin ich für jeden Wegweiser dankbar, den ein anderer Mapper erfasst, fotografiert und nach Mapillary hochlädt oder dessen Existenz er mit check_date bestätigt.
Daas klingt so, als ob Du Dir eine Pflicht auferlegt hättest, die Dir eher Leid als Freude bringt. Da machst Du aus meiner Sicht was falsch.
Das mit den Fotos habe ich ja vor einiger Zeit auch mal vorgeschlagen, aber ich fürchte, dass mir das Hochladen von Fotos weit weniger Freude machen würde als das Hinfahren und nachschauen.
Wenn es Dir keinen Spaß macht, irgendwo hin zu radeln, um nachzuschauen, ob der Wegweiser noch da ist, dann solltest Du es lassen. Wenn es Dir aber Spaß macht, dann sollte es egal sein, ob da ei Wegweiser steht, den jemand anders 3 Tage vorher auch schon nachgeprüft hat.
I’m not the OP, but I still don’t get your reasoning. I can go to pub tomorrow alone, have a few beers by myself, and enjoy it. I’d however like it even better if I do it in collaboration with others. One doesn’t exclude the other, surely that is self-evident?
Same with mapping: sure, I can go and map whole town by myself (and have done so on occasions, and loved it). Yet I loved it much more when others joined and we collaboratively mapped, and managed to map much more together, instead of each of one needlessly duplicating one another’s work.
It is the useless waste of time by repeatedly doing things that were already done by others that I’d like to avoid; not the work itself.
