Thus the solution should be simple - people from the second group who don’t care should just ignore those tags, and let people who care about them use them happily ever after. That is only reasonable solution.
there are other possible solutions, e.g. create a parallel database to log data checking without modification and use this instead of creating new versions of OpenStreetMap objects without changing anything
so one OSM db with buildings and one without? 
check_date data is a valid information. Maybe not for you. That’s ok.
check_date data is a valid information. Maybe not for you. That’s ok.
it is not, it is meta information not in any way bound to reality, one might also say it is mapping “events” which is frowned upon in general. You cannot verify the last checked property on the ground, it creates noise when nothing has changed, it doesn’t ultimately belong aside the factual data, the only reason it is put along descriptive information is that it is easier this way.
Diese Argumentation möchte ich bitte zukünftig auch unter jeder Erwähnung von Micromapping, unwesentlichen Änderungen usw. lesen.
Und dann beschwere ich mich darunter, dass jeder Beitrag im Forum und generell jeder Kommentar ebenso Speicherplatz erfordert. Deal? 
Und wenn ich da erst an die Abfragen, deren Protokollierung usw. denke… 
That is comparing apples with oranges. One (the buildings) is geoinformation belonging into a geoinformation-database. As @dieterdreist already said, the other one (timestamps) is just some metadata about that geoinformation. No doubt that the checkdates might be useful in some cases*, but does it really belong into the same database as the geoinformation?
*) In my starting post I was wondering why we suddenly need a check_date for the asphalt-surface of a highway=primary that has been asphalt ever since it was built decades ago. This information is so utterly useless that I find it hard to just ignore it. It’s useless-level is somewhere around the cycleway:both=no on German motorways and the latter would at least be geoinformation.
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)…
That’s the point
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.
So come and support tag change dates/flags · Issue #26 · osmlab/osm-data-model · GitHub for better way to store such useful metainfomation (as noted before), right? I do acknowledge that it would be superior place for storing such metainformation.
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)
None of that changes my main point though: live and let live
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!) 
source:date (28,3 Mio. Verwendungen) oder survey:date (1,2 Mio. Verwendungen) sind auch so Meta-Tags, die es schon ewig gibt:
https://taghistory.raifer.tech/#***/source:date/
https://taghistory.raifer.tech/#***/survey:date/
Worauf (auf welche Tags) die sich dann beziehen ist dann nur leider unklar.
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.
aren’t tag changes available in josm in the history viewer (ctrl+h)? The issue is with tags that don’t change
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.