Das wäre aus meiner Sicht weder ein Problem noch wird es in der Praxis oft passieren. Wenn ich feststelle, dass in einer Gegend ein andere Mapper sehr aktiv ist, dann werde ich dort entweder weniger aktiv oder spreche mich evtl. ab.
Es gibt einige gute Gründe dagegen, viele Tags an ein Objekt zu kleben.
- Man braucht entweder riesige Monitore oder viel Zeit, um nachzuschauen, welche Tags an dem Objekt dran sind, dass man evtl. bearbeiten will. Je mehr da ist, umso wahrscheinlicher übersehe ich etwas und ergänze evtl. etwas, dass im Konflikt mit anderen Tags steht.
- Die checkdate:* Tags sind genauso fragwürdig wie andere Tags, sie sind nur neuer und dadurch zur Zeit noch nicht so wahrscheinlich falsch wie surface an einer Straße, die lange nicht geändert wurde.
- In dicht bebauten und gut gemapten Gegenden wird man immer mehr Probleme bekommen, ein nennenswertes Rechteck von Daten per API abzurufen, ganz zu schweigen davon, das Editoren und andere Programme immer mehr Speicher benötigen.
Die checkdate* Tags sind für mich genauso störend wie ein source=survey an jedem Objekt.
1 Like
Alles nachvollziehbar, aber die Anzahl der Tags wird grundsätzlich immer mehr. Wenn die Editoren damit bisher nicht gut umgehen können, würde ich das Problem jetzt eher dort suchen. Wenn ein Editor das checkdate:-Tag z.B. korrekt handhabt, würde er den Wert gar nicht erst anzeigen, sondern einfach bei Änderung setzen und gut, vielleicht ansonsten beim Drüberhovern als Tooltip zeigen. Dasselbe gilt für zu große Bereiche. Dann soll der Editor das eben stückeln.
Falls Du mal in einer Gegend mit vielen 3D-Building-Tags gearbeitet hast, wird Dir sicher auch schon sehr oft aufgestoßen sein, dass JOSM das nicht gut handhabt. Ständig erwischt man ein building:part=yes statt des Gebäudes selber. Ich habe die Datenmenge in meinem Gebiet sicher schon mehr als verdreifacht, weil ich jedes Haus in seine Teile zerlegt und getaggt habe. Und da kommt weiß Gott mehr dazu als ein checkdate:, weil ich immer Stockwerke, Höhe, Dachform, Dachhöhe, etc. erfase - also eigentlich immer mindestens 4 Tags, meistens mehr. Würde deswegen jemand das 3D-Tagging schlecht finden? Nein.
Und wie ich bereits sagte: Attribute machen an Datenmenge wirklich nur einen kleinen Teil aus und lassen sich auch wunderbar komprimieren. Das Gros kommt von Nodes.
Nochmal: ich bin kein Fan dieses Tags, aber solange das von OSM nicht direkt in der Datenbank für die Attribute unterstützt wird, gibt es nicht wirklich eine Alternative. Ich würde mir da eher guten Support in den gängigen Editoren für Tags wünschen, die mich nicht interessieren. Mag ja eine Nischenmeinung sein, aber ich erfasse die Dinge gerne sehr genau, sonst könnte ich auch einfach die Daten vom Konkurrenten mit G nehmen.
2 Likes
Dafür müsste dann JOSM die Logik kennen, die die Apps verwenden und denen ständig hinterherhinken. Wenn ich das richtig verstanden habe, dann fragt SC geziehlt für ein Objekt eine Eigenschaft ab und setzt dann voraus, das diese Eigenschaft gerade vor Ort geprüft wurde. Das kann JOSM gar nicht leisten. JOSM hat ja viel mehr Möglichkeiten, die Eigenschaften von Objekten zu ändern. Der Bearbeiter müsste dann jeweils angeben, ob und wann die Eigenschaft vor Ort geprüft wurde. Ich zum Beispiel mappe manche Details Tage oder Wochen nach der Besichtigung und ändere dabei auch mal die Lage von Objekten nach Luftbild oder die Eigenschaft nach Erinnerung. Wenn dann an jeder Änderung ein checkdate* dran gehängt wird, werden meine Daten nicht besser, sehen aber für andere besser aus 
Auf einige Tage oder Wochen wird es schwerlich ankommen, wenn Dinge einmal im Jahr oder noch seltener geprüft werden.
Und wenn Dein Argument ist, dass die Dinge, die Du einträgst / änderst schon nicht mehr aktuell sind, weil Du so lange damit gewartet hast, solltest Du eher Dein Vorgehen ernsthaft überdenken.
Wenn Du Dir sicher bist, dass es noch korrekt ist, braucht es doch nicht 4 Wochen später erneut geprüft zu werden.
Du verstehst nicht, worauf ich hinweisen möchte.
Wenn ich denken würde, dass die Daten gar nicht mehr stimmen, dann würde ich sie nicht mehr mappen. Ich habe aber keine Lust, bei hunderten oder tausenden von geänderten oder neuen Objekten jeweils zu überlegen, ob SC da ein checkdate setzen würde und - falls ja - das dann selber händisch einzutragen.
Ich hab das jetzt nicht geprüft, aber ich meine, dass SC auswertet, wann ein Tag das letzte Mal geändert wurde. Das checkdate: kommt ja nur ins Spiel, wenn es nicht geändert wurde. Du musst Dir also beim Mappen keinerlei Gedanken machen, da Du ja nur Änderungen erfasst.
Warum wurde dann oben gesagt, dass man Daten, die kein checkdate haben, weniger vertrauen kann?
1 Like
Wenn jemand vor 2 Tagen die opening_hours eingetragen hat, ist das genauso aktuell, wie check_date:opening_hours auf ein Datum von vor 2 Tagen.
Wenn sich jetzt die Öffnungszeiten 10 Jahre lang nicht ändern, würde auch niemand Änderungen an ihnen durchführen, weswegen man nach 10 Jahren langsam unsicher wäre, ob die noch aktuell sind, oder einfach keiner die überprüft hat.
In diesem Fall hilft einem check_date: zu wissen: alles klar, die haben sich Stand X nicht geändert.
9 Likes
Ich verwende check_date/ check_date:* auch wenn ich Daten ändere. So wie GerdP trage ich manchmal auch Dinge erst Wochen (oder Monate) später ein und damit dokumentiere ich den Zeitpunkt der Datenerhebung.
Das stimmt, aber ich denke, dass check_date deutlich einfacher auszuwerten ist. z.B. für die weiter oben von mir gewünschte Anzeige der Öffnungszeiten.
1 Like
Das kommt auf die Datenquelle an. Wenn man direkt auf der PostgreSQL-Datenbank arbeitet, ist das kein Problem und wer wirklich gute Daten haben möchte, sollte check_date: und die Changesets durchgehen. Beides hat seine Daseinsberechtigung.
Ok, ich kenne mich der Technik hinter OSM nicht aus und komme auch nicht aus diesem Bereich.
Jedenfalls muss man festhalten, dass Changeset-Datum nicht gleich Erfassungsdatum ist. Ich mappe die Dinge selten am selben Tag. Und selbst bei SC lade ich nicht immer alles am selben Tag hoch. Bei anderen habe ich gesehen, dass sie das Datum der Datenerfassung in den CS-Kommentar schreiben.
Ich finde die Intention von SC in diesem Bereich ja auch sehr gut, nur so die Einschätzung, wie oft manche Tags geprüft werden müssten, halte ich - zumindest mal für DE gesprochen - für vollkommen überzogen.
Zum Beispiel die an Recyclingcontainern geprüften Materialien alle 2 Jahre zu überprüfen. SC-User können die Quest ja dann noch mit der “Frage mich das doppelt so oft”-Einstellung jedes Jahr bei sich aufploppen lassen. Mach’ das mal mit einem Objekt das bin, bench, lit, shelter, tactile_paving und sonstiges Gedöne dran hat (z. B. Bushaltestellen) und man nehme dann eine Großstadt, 6-7 Tags jedes Jahr gecheckt macht 6×5=30 neue Objektversionen in fünf Jahren nur für SC.
I’d like to make an observation. After several dozen messages, it is hopefully clear to everyone that:
- there are some number of people who care about
check_date:*tags (for various reasons - it is not even important which reasons, just that some people care!) - there are also some number of people who don’t care about
check_date:*tags at all.
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.
Let’s make some parallel - I for example personally don’t care much about building=* polygons and find them useless waste of space. Yet, I have become aware (for example after a long thread) that there are some people who care about them – even if I cannot fathom the reasons why anybody would care about buildings.
Solution is equally simple: I ignore those buildings and go map things that I think are useful and leave those building-caring people do their thing. I do not go on crusade how all building=* polygons should be deleted and people should stop mapping them as they are useless to me and make my downloads take longer or confuse me when I map roads nearby or whatever. Nor do I insist that they explain to me over and again why they find it useful and then write up posts why their reasons do not apply to me because I don’t care about buildings. I just let them live and map their thing, even if I find it useless. 
6 Likes
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
3 Likes
so one OSM db with buildings and one without? 
1 Like
check_date data is a valid information. Maybe not for you. That’s ok.
2 Likes
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.
4 Likes
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… 
1 Like
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.
3 Likes