Verstehe ich nicht. Wenn CodeMirror deaktiviert ist, fehlen natĂŒrlich solche Annehmlichkeiten wie Syntax Highlighting. Aber man kann doch trotzdem editieren (also ich zumindest).
Da ist bei mir ein schwarzes Loch. Die nÀchste ist erst 12 km weit entfernt.
Die Anmerkung â(auf mobilen GerĂ€ten deaktivieren; Ănderung wirkt erst nach App-Neustart).â passt schon. Mit aktivem CodeMirror kann ich die Query nicht anpassen unter Chrome, sowohl auf Android als auch iPhone.
Mit Firefox fĂŒr Android habe ich da sowohl mit als auch ohne CodeMirror kein Problem (mit ist natĂŒrlich schöner). Insoweit fĂŒr mich wirklich in keinster Weise nachvollziehbar.
Ich finde es nicht sooo gut, jedes ĂŒberprĂŒft eObjekt mit lastcheck oder welchem tag auch immer zu versehen - wenn sich das durchsetzt, wird es die history unnötig aufblĂ€hen. Meiner Meinung wĂ€re so etwas wie der OSM Tasking manager sinnvoller.
+1 Genau deshalb hab ich mir gedacht das Thema wieder auf den Tisch zu bringen
IMHO sollte ein Aktualisierungstag nur gesetzt werden, wenn wirklich ausdrĂŒcklich alle tags gecheckt wurden.
Und genau diese Datenleichen werden immer mehr, wenn es weitergeht wie bisher. Die Frage ist also, was kann man tunâŠ
Mein Vorschlag wĂ€re ein Proposal mit einem festen Vorschlag fĂŒr folgende Punkte:
Welches Tag wird benutzt.
Welche Typen sollen damit versehen werden (amenity=,shop= whatever)
Wann wird das tag gesetzt/aktualisiert
Dann ins Wiki damit mit Hinweis auf Tools die die Bearbeitung unterstĂŒtzen. Und um mit gutem Beispiel voranzugehen dann vielleicht eine Wochen-/Monatsaufgabe, damit auch endlich was ins Rollen kommt :)
Sollte doch mit der âdeutschen GrĂŒndlichkeitâ möglich seinâŠ
Es geht wohl primĂ€r um bestimmte POI, bei denen sich main- oder sub-tags regelmĂ€Ăig Ă€ndern, wie z.B. shops, tourism und amenity. Ob sich dabei - selbst bei verbreiteter Anwendung - die GröĂe der Datenbank wesentlich erhöht, darf bezweifelt werden. Es wĂ€re aber m.E. ein nicht unwesentliches Merkmal im Sinne der QualitĂ€tssicherung, die umso wichtiger ist, je Ă€lter ein Objekt ist.
Ich finde auch, daĂ wir dringend ein Verfahren brauchen um festzuhalten, daĂ die Objekte ĂŒberprĂŒft wurden. Wie gesagt, einen tag auf den Objekten selbst finde ich aber nicht ideal.
und hat laut http://taghistory.raifer.tech/ mit weitem Abstand die gröĂte Verbreitung, also sollten wir es vielleicht einfach verwendenâŠohne weitere proposals
Nunja, es ist âaufgelistetâ - dokumentiert wĂ€re irgendwie ausfĂŒhrlicher. Deshalb sind all diese Fragen ja offen und keiner weiss bescheid wie es gemacht werden sollte. Guckt euch mal hier die ganzen Hausnummern an
Also wenn es so aufgedröselt wird, bekomme ich doch ein paar Bauchschmerzen. Mal davon abgesehen, dass man dann vor lauter Keys ĂŒberhaupt nicht mehr fertig wird mit der Dokumentation einer Kontrolle, wird das auch extrem unĂŒbersichtlich. Wir haben parallel diese Tankstellendiskussion, wo einige schon allein jeden der rund 20 Fuel-Keys taggen wollen (ggf. als ânoâ). Wenn dafĂŒr dann auch noch 20 Survey-Keys hinzukĂ€men, zusĂ€tzlich dann noch solche Dinge wie Ăffnungszeiten, x Zahlmöglichkeiten, Brand, dann haben wir in Zukunft regelmĂ€Ăig EintrĂ€ge mit 50 bis 60 Keys. Das ist irgendwo nicht mehr sinnvoll zu handhaben. Zumal dann auch die VersionshĂ€ufigkeit steigt, weil vermutlich jeder nur ein paar Teilaspekte prĂŒft und somit hĂ€ufiger die Dokumentationszeitstempel aktualisiert werden mĂŒssen.
Also dort sollte man doch ein sinnvolles MaĂ finden und ggf. auch mal Mut zur LĂŒcke haben. Es ist besser wenn jemand vielleicht auch nur 80 Prozent des Umfangs prĂŒft und das trotzdem einheitlich dokumentiert, statt dass ein solches Chaos angerichtet wird, was niemand mehr beherrscht.
Die History wird nicht aufgeblÀht; sie wird ergÀnzt. Es wird gezeigt, daà das Obejtk noch aktuell und keine Karteileiche ist. Ein Objekt in dessen History alle 6 Monate ein check_date (oder was auch immer) aktualisiert wird, ist besser, als eines dessen Historie seit 7 Jahren unverÀndert ist.
Ich denke manchmal sogar, daà es vielleicht sogar gut wÀre, wenn veraltete POIs nicht mehr in der Hauptkarte angezeigt oder mit einem Fragezeichen versehen werden.
Ich finde auch, dass erst ein mal eine Grundbasis funktionieren sollte, bevor am Ende völliges Chaos herrscht. Lediglich die wichtigsten keys zu checken und trotzdem âaktuellâ eintragen finde ich ok - aber die reine Existenz oder ein einzelnes tag als aktuell zu deklarieren bringt nicht wirklich eine Verbesserung der DatenqualitĂ€t.
Zum Thema History sehe ich eigentlich keine Probleme - ist die nicht genau fĂŒr soetwas da?? SchlieĂlich sollte ja nicht alle 6 Wochen aktualisiert werden; ausreichend dĂŒrften 6 Monate - 2 Jahre sein (je nach Typ des POI)
Ansonsten könnte auch ĂŒberlegt werden wann man das Objekt als aktuell taggt. Wenn man survey:date zB nur dann hinzufĂŒgt wenn die letzte Ănderung lange her ist und noch alles identisch ist wird die History nicht allzusehr âbelastetâ. Das survey:date könnte bei einer Ănderung des POI wieder gelöscht werden, der Timestamp wĂŒrde dann genĂŒgen (und es gĂ€be keine Konflikte Timestamp vs survey:date). Allerdings wĂ€re dieser Workflow meines Erachtens wieder zu kompliziert was die Beteiligung hemmt.
Einfacher: survey:date wird bei JEDER Ănderung auf das aktuelle Datum gesetzt (ein Auswertungstool sollte beachten, dass das auch mal vergessen wird); wenn der POI identisch ist wird es frĂŒhestens nach 6 Monaten neu gesetzt (btw: sollte reichen um immer genug zu tun zu haben :D)
@Kontinentalverschieber, du hast den Konjunktiv ĂŒberlesen Es kann sinnvoll sein, nur die PrĂŒfung einzelner sub-tags zu dokumentieren. Ich habe nicht angeregt, das flĂ€chendeckend zu machen. Datenkonsumenten sollten damit ohnehin kein Problem haben. Es war primĂ€r ein Kommentar zum kategorischen Vorschlag von Sir_Blight, eine Aktualisierung nur zu taggen, wenn âausdrĂŒcklich alle tags gecheckt wurdenâ. Das wĂ€re zwar prinzipiell wĂŒnschenswert, aber in der Praxis unrealistisch und nicht durchsetzbar.
FĂŒr den im OP genannten Zweck erscheint mir das Landshuter Tool bestens geeignet. Habt Ihr das schon bei euch ausprobiert? Die Spalten kann man ĂŒbrigens sortierenâŠund so mit den âFossilienâ anfangen: http://osm.edvbl.dyndns.org/poi_lastcheck/
Vielleicht wĂ€re das was fĂŒr den Editor⊠âDu ein Cafe (o.Ă€.) geĂ€ndert, war es eine technische oder inhaltliche Ănderung?â
Technisch, im Sinne von Kontinentalverschieber, dass irgendwas am Objekt gebastelt wurde â kein Survey Tag
Inhaltlich im Sinne einer ĂberprĂŒfung â Survey Tag, entweder aus Timestamp abgeleitet (default) oder es wird nach Datum gefragt, falls dieses Abweicht.
Die Unterscheidung könnte halbautomatisch sein. Wenn keine Tags geÀndert wurden, deutet es eher auf was technisches hin. Das Verschieben eines POI kann beides sein.
Das wĂ€re falsch. Ich kann einen POI editieren, ohne alle Daten ĂŒberprĂŒft zu haben. Wenn ich einen falsch geschriebenen shop-Tag korrigere oder eine Anschrift ergĂ€nze, bestĂ€tige ich damit noch nicht die Ăffnungszeiten; mit check_date hingegen bestĂ€tige ich die AktualitĂ€t aller Daten.
Ich bin fĂŒr das manuelle Setzen von check_date und co. Es ist wie ein PrĂŒfstempel dem ich den Objekt mitgebe.
Zu ĂŒberlegen wĂ€re, ob man Untertags einfĂŒhrt, z.B. daĂ man zwar die bloĂe Existenz eine Objektes bestĂ€tigen kann, nicht aber alle Eigenschaften.
Weiteres Beispiel zum vorherigen Kommentar: Man kann auch Teilweise den POI-Punkt leicht verschieden, das setzt auch das Ănderungsdatum hoch ohne, dass man irgendwelche Tags angefasst hat.
Subtags halte ich nicht so sinnvoll, denn es verkompliziert die Sache unnötig und wenn man Tags ĂŒberprĂŒft, sollte man alle ĂŒberprĂŒfen.
Entschuldigt⊠ich habe mich missverstĂ€ndlich ausgedrĂŒckt. Ihr habt natĂŒrlich recht. Mit âjeder Ănderungâ meine ich, wenn man im âCheck-Modusâ arbeitet - also POI prĂŒft und feststellt, dass sich einer geĂ€ndert hat. Dann werden alle (oder zumindest die meisten) Tags aktualisiert und das survey:date gesetzt.
Wenn lediglich im âTagesgeschĂ€ftâ eine Kleinigkeit geĂ€ndert wird und der Rest garnicht geprĂŒft wurde wird natĂŒrlich kein neues Datum gesetzt, sondern ein ggf. vorhandenes so belassen - da stimme ich euch zu.
Dann gibt es zum Auswerten 3 ZustÀnde (wenn ich keinen Denkfehler hab):
nur timestamp â wenn neu: ok; wenn etwas Ă€lter: auf die PrĂŒfliste
timestamp und survey:date sind gleich â es wurde zuletzt geprĂŒft, also: ok. Wenn lange her: auf die PrĂŒfliste
timestamp ist neuer als survey:date â zuletzt wurde evtl nur verschoben, ein Teil korrigiert oder Ă€hnliches: je nach Zeitdifferenz abwĂ€gen ob ok oder auf die PrĂŒfliste.
Das Tool ist vom Grundsatz nicht schlecht; kenne ich zum Ausprobieren erst jetzt. Ich dachte das Projekt wÀre nie richtig realisiert worden, weil es unter der Wikiseite keinen Link zum Tool gibt - oder bin ich blind?
Eine gerade letzte Woche gemachte Erfahrung zur Problematik: emergency_access_points im Spessart wurden groĂteils neu beschildert, bekamen neue refs, manche verschwanden aber auch. Meine Kontrolle auf AktualitĂ€t hatte ich bisher via timestamp gefiltert. Jetzt hat ein mapper pauschal die Tel.nr. 112 per couchmapping eingetragen, aber dadurch fĂŒr mich die Illusion geschaffen, der POI sei aktuell, wo er tatsĂ€chlich aber entfernt wurde. Aufgefallen war mir dies nur zufĂ€llig durch ein anderes Ăberwachungstool. Daher ist ein last_check Datum bei gravierenden Infos hilfreich.
Cepesko
Dito, ich habe das schonmal irgendwo gesehen, aber keine weitere Beachtung geschenkt. Ich werde fĂŒr mich bald ein bisschen damit rumspielen und schauen ob ich mir was abschauen kann.
Kannst du in deine Auswertung eine Misstrauensliste einbauen? Sprich Nodes, die dieser Nutzer zuletzt bearbeitet hat, werden mit auf die Liste gesetzt?
Ich habe vor den umgekehrten Weg zu gehen, wenn ich ein GefĂŒhl dafĂŒr bekomme wie lange POI aktuell bleiben. Dann habe ich vor, âmeinenâ Nodes lĂ€nger zu vertrauen als fremden. Bei âmeinenâ weiss ich, dass sie komplett ausgefĂŒllt sind, so kann ich mich etwas mehr auf möglicherweise unvollstĂ€ndige konzentrieren.