Ja, das geht schon in die richtige Richtung, aber wenn es nicht direkt auf der Karte selbst verlinkt, oder gar eingebunden ist, wird das auch keiner finden und nutzen.
Am besten wäre natürlich, wenn man diese Notes separat suchen könnte, denn selbst als Ortsfremder kann ich ja halbwegs beurteilen, ob die angegebenen Daten stimmig sind. Im Vergleich zu „normalen“ Notes, wo man dann nur "muss mal überprüft werden“, oder „hier ist jetzt ein Adam’s oder so drin“ bekommt, sind die von OnOSM ja ein Gedicht. Aber ich wollte damit jetzt nicht zu sehr OT werden, vielleicht sollte ich das mal an anderer Stelle anregen, in die Karte einzubinden.
Auf NotesReview kann man gezielt nach diesen Notes suchen:
- Unter Filter › Query nach
onosm.orgsuchen - Anonymous notes muss eingeschaltet sein
- Bei Bedarf noch Search only in current view einschalten
2 Likes
Seh ich auch so… bis es “technisch” eine besser Lösung gibt… gibt es halt ganz viele check:* aber der Editor könnte es ja verstecken und hinter einem Key/Value eine grünen Hacken machen, wenn erst überprüft wurde… mit Tooltip und Datum z.B. als Idee ;). Dann wäre es aus der Liste und gut.
Irgendwie muss man ja kenntlich machen das man dies oder das schon überprüft hat.
Gruß Miche
1 Like
Wer sein lokales Gebiet up-to-date halten möchte kann die Verwaltung auch lokal in Excel oder so machen. Ansonsten reicht es IMHO die bestehenden QM-Tools zu nutzen um überprüfungswürdige Objekte zu finden. Dazu muss man nicht die DB mit Meta-Tags vollkleistern.
1 Like
in Excel 
… ja klar… das ist ja mal eine geniale Idee.
Naja jeder kann es besser machen… aber hier immer an StreetComplete rumzumeckern, macht es auch nicht besser. Wenn einer eine besser App schreibt dann nutze ich diese gerne… aber momentan ist das nicht der Fall
Gruß Miche.
Interestingly, JOSM already does have support for discardable tags in tags.discardable advanced preference. Although adding tags to that list would hide them from Tags pane (assuming default display.discardable-keys=false), it will also silently remove them on upload if element was modified (which is not ideal - it would be much better if the validator like one suggested below would ask the user what they want to do in situation of such conflict, see below)
For those interested, I’ve suggested this in #22816 (Check for check_date:xxxx if tag xxxx is updated (and offer to fix it)) – JOSM as it is quite useful in itself.
3 Likes
Wie nutzt man die vor Ort auf dem Smartphone gescheit und kann auch gleichzeitig noch die OSM-Db aktualiseren?
Excel? Das mit den tollen Makros von Microsoft? Dann kann ich ja gleich Google Maps und Google Docs nutzen. 
… nutz doch Calc von LibreOffice. 
1 Like
Menno, das war doch nur ein Beispiel mit dem Excel.
Man kann natürlich auch mit Stichtag arbeiten, zB. dass man am Anfang jeden Jahres alle Restaurants und Bäcker seines Ortes überprüft.
Ich wollte nur damit sagen, dass es noch andere Möglichkeiten gibt als dieses check_date:*
Ja, aber leider ist kein dieser Möglichkeiten sinnvoll und mit Bordmitteln von anderen OSM-Nutzern benutzbar. Wenn nicht nur ich wissen möchte, wann das letzte Mal ein POI überprüft wurde, und welche Attribute davon, gibt es leider derzeit keine sinnvolle Alternative 
7 Likes
Und dann prüfen in gut versorgten Gebieten 15 Mapper:innen jedes Jahr das selbe Objekt, weil jeder seine eigene Liste führen soll?
4 Likes
Mich interessiert auch nicht ob und wann ein anderer Mapper einen POI überprüft hat. Entweder die Informationen stimmen oder man muss entsprechend agieren.
Das ständige Aktualisieren von check_date:* verbraucht nur Speicherplatz in der Geodatenbank. Und außerdem hebelt das check_date-Tagging die QA-Funktion von Vespucci aus. Diese App wertet den Zeitstempel von Objekten aus, sprich die letzte Änderung.
Der Zeitstempel sagt überhaupt nichts über die Aktualität der Attribute aus. Wenn ich aus einem Luftbild heraus den Verlauf einer Straße korrigiere, ändert sich deren Zeitstempel, aber ich habe ganz sicher nicht überprüft, ob da immer noch 50 km/h sind. Man muss immer betrachten, was genau geändert wurde und wenn eben nichts geändert wurde, kann das heißen, dass sich nichts geändert hat, aber auch, dass niemand geschaut hat. Meistens aber, dass keiner geschaut hat.
Das ist dasselbe Problem wie mit den Default-Werten. Ein nicht vorhandenes Attribut in OSM kann bedeuten: ist der default, kann aber auch heißen: keine Ahnung, trag’ ich mal besser nicht ein, oder: wusste gar nicht, dass es das gibt.
Das ewige Argument mit Speicherplatz kann ich übrigens nicht nachvollziehen. Ein Extra-Attribut braucht in OSM in der Regel weniger Platz als ein Extra-Node an einem Weg. Und bisher hat sich ja auch noch niemand beschwert, dass einige Leute den Kreisverkehr mit 10 Punkte und andere mit 100 Punkten erfassen.
9 Likes
Haste eigentlich vergessen? Die OSM-Datenbank ist wie Wikipedia ein System welches mit Versionen funktioniert. Sprich jede Änderung wird nur hinzugefügt. Alte Daten verbleiben in der Datenbank. Auch beim Löschen von Nodes/Ways/Relation werden die Daten nur ausgeblendet.
1 Like
Haben sich die Betreiber denn schon mal beschwert, dass die Datenbank zu groß wird, und wir weniger Tags benutzen sollen, oder ist es nicht eher so, dass das Argument mit dem Speicherplatz immer dann ins Feld geführt wird, wenn einem ein bestimmtes Tag nicht gefällt?
2 Likes
Ja, die DWG greift zum Beispiel bei Edit-Wars ein, da das ständige Ändern schlicht unsinnig und die Versions Nummer nur unnötig nach oben treibt.
Edit: typo
Und das hat jetzt welchen Bezug zu check_date:*? Hat sich die DWG beschwert, dass das ewige Bestätigen eines Datums zu viele Daten erzeugt? Versteh mich nicht falsch, ich hätte da auch gerne eine bessere Lösung, so wie von @SimonPoole geschrieben:
Aber solange es eben keine bessere Lösung gibt und sich die DWG nicht über das Volumen der Daten beschwert, finde ich das Argument nicht überzeugend.
2 Likes
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