Qualitätssicherung

Da ich hin und wieder Briefkästen kontrolliere und Daten ändere folgende Frage:

9 970 x lastcheck
567 x last_check
59 353 x check_date
3 221 x last_checked

(ich habe bisher lastcheck=YYYY oder TT-MM-YYYY genutzt)

Was sollte man eventuell im WIKI festlegen? (zur Zeit keine Festlegung).

Ich würde mich bei Festlegung für

(109x) check_date:collection_times=TT-MM-YYYY
auch für (516x) check_date:opening_hours oder (14x) check_date:xmas:day_date

dann sollte aber z.B. (10x) collection_times:check_date oder (71x) opening_hours:check_date umgemappt werden.

Und beim WIKI-Eintrag Hinweis: “lastcheck, last_check, last_checked nicht mehr zu verwenden”

Ist es eigentlich nicht besser, wenn man z.B. (3x) surface:check_date in (2+3x) check_date:surface umschreibt?

Oder auch (2x) collection_times:last_checked → check_date:collection_times=*
oder auch (567x) last_check in lastcheck=*

Dann ist auch bei der Suche nach einen passenden Schlüssel jeden mehr geholfen, weil weniger Auswahl.

EDIT: Briefkastenkarte

Eine gute Hilfe für die Umgebung: http://www.briefkastenkarte.de/#zoom=14&lat=50.73376&lon=7.09759

Das lastcheck wird überwiegend in DE genutzt - ckeck_date:= weltweit:
https://taginfo.openstreetmap.org/keys/lastcheck#map
https://taginfo.openstreetmap.org/keys/check_date#map

Allgemein weit verbreitet ist auch survey:date (390 430 x) bzw. - deutlich weniger - survey_date (3694 x).
Da gibt es durchaus Überschneidungen

“(ich habe bisher lastcheck=YYYY oder TT-MM-YYYY genutzt)”

Mmh, wenn etwas vereinheitlicht werden soll, dann würde ich jedenfalls für das gebräuchliche
YYYY-MM-DD (bzw. JJJJ-MM-TT) nach ISO 8601
plädieren. Ob die umgekehrte Variante überhaupt normiert ist, weiß ich nicht.

Prinzipiell kann man das check-Tag ja auch noch erweitern mit dem was gecheckt wurde. Also bspw. check:opening_hours=*, dann weiß man, dass die Öffnungszeiten kontrolliert wurden, die anderen Angaben aber evtl. nicht. Sprich: für jedes Tag könnte man noch ein check-Tag dranpappen. So ist es vielleicht nicht direkt sinnvoll, aber zumindest in der Art und Weise könnte es Sinn machen. Momentan denke ich macht es am meisten Sinn nach dem Modell check_date:opening_hours=YYYY-MM-DD und dann checkt man halt was man für checkeswert hält. Vielleicht kann man da in Zukunft das ja auch genauer ausarbeiten wo es Sinn macht, wo weniger…

Zur anderen Frage: last_check oder Derivate gefallen mir nicht so, denn die implizieren, dass nach dem Datum nicht mehr gecheckt wurde. Vielleicht wurde es aber, nur das Datum wurde nicht angepasst. Insofern gefällt mir was mit check besser. survey klingt für mich ein wenig hochtrabend und außerdem denke ich check dürfte in der nicht-englischsprachigen Welt verständlicher sein als survey…

Und irgendwann sieht es so aus:

  1. Ist hier noch der Friseur OpenHair? → check_date:shop=YYYY-MM-DD, check_date:name=YYYY-MM-DD
  2. Hat der Friseur noch die und die Öffnungszeiten? → check_date:opening_hours==YYYY-MM-DD
  3. Ist der Eingang noch rollstuhlgerecht? → check_date:wheelchair=YYYY-MM-DD
  4. usw.
  5. usf.

Wäre dann wohl etwas für einen StreetComplete-Nachfolger namens StillCorrect. :wink:

Vermutlich nicht.

Ich finde es sowieso eine Unart, hier die falschen Zeichen zu verwenden. Generell. Wenn es auf Verständlichkeit ankommt, verwendet man JJJJ-MM-TT, am besten sogar immer, ansonsten TT.MM.JJJJ oder, je nach Kulturkreis, MM/TT/JJJJ.

Leute, die TT/MM/JJJJ, TT-MM-JJJJ oder Schlimmeres schreiben, gehören mal gehörig auf die Folgen ihres Tuns hingewiesen.

Darum ging es eigentlich nicht - es geht um eine Festlegung im WIKI und dann entsprechende Änderung. Natürlich sollte dann das Basisformat: 20030107 = YYYYMMDD oder das Erweiterte Format: 2003-01-07 = YYYY-MM-DD mit festgelegt werden.

korrigiert

Ist auch in dem Vorschlag von mir so gemeint. Eventuell kann man
check_date=YYYY-MM-TT
für die Prüfung “aller” Angaben nutzen.

Moin!

,anfangs habe ich auch lastcheck verwendet und dann hatte man mich auf check_date umgestimmt,was ich auch für meine Tags angepasst habe.

Das survey wird, sowrit ich mich erinnere, mehrheitlich von einer Software automatisch erstellt und gibt Null Auskunft darüber wie aktuell die letzte Prüfunh ist!

Das entgültig eine Regelung her muss sehe ich auch so - ebenso ein automatsches Umtaggen in besonderen Fällen der Schreibformanpassung.

;Jan

Ein Vorschlag, dem ich uneingeschränkt zustimme. :slight_smile:

Ich habe die deutsche WIKI-Seite ergänzt:
https://wiki.openstreetmap.org/w/index.php?title=DE%3ATag%3Aamenity%3Dpost_box&type=revision&diff=1530080&oldid=1523660

Eventuell sollte es ins WIKI-englisch übertragen werden - kann ich aber nicht.

Eine Übersetzung der Seite https://wiki.openstreetmap.org/wiki/Key:check_date sollte vielleicht auch erfolgen. Dort könnte dann bei lastcheck, last_check ähnlich verwiesen werden. Und die Erweiterung check_date:= einbezogen werden.

PS (meine Meinung):
in einem anderen Thema habe ich einmal gelesen, es soll nicht “deutsches” Tagging eingeführt werden, da es in Peru vielleicht nicht zutreffend ist.
Ich finde das nicht unbedingt richtig: Vielleicht fehlt in Peru genau dieser Taggingvorschlag, der dort nur durch einen anderen Schlüssel das gleich aussagt. Es sollte doch keinen hindern, einen Vorschlag aus anderen Ländern zu übernehmen. Es kann ja auf der englischen Seite als DE: markiert werden.
Und auch bei geringen neuen Schlüsseln sollte reagiert werden:

Den Ersteller auf das umtaggen und den Schlüssel verweisen. Damit vereinheitlichen wir zumindest die Schlüssel etwas.

Noch eine Frage:

Es gibt in JOSM eine Vorlage (Einrichtungen/Einrichtungen/Briefkasten).

Wie kann diese erweitert / korrigiert werden? (Referenznummer → Referenz, Marke=, Prüfung=)

Da kommt es immer wieder zu Problemen. Man kann natürlich etwas festlegen … aber das sorgt nur dafür, dass die Schuldfrage geklärt wird.

Man sollte besser eindeutig formulieren: “01-FEB-2003” kann man nicht versehentlich oder aus Unkenntnis mit einer anderen Bedeutung schreiben oder lesen.

Eine Festlegung auf TT-MMM-JJJJ mit MMM als den ersten drei Zeichen des englischen Monatsnamens wäre für jeden eindeutig verständlich.

Ich hatte gehofft, dass nach der Diskussion vom letzten Jahr:

https://forum.openstreetmap.org/viewtopic.php?id=53339

für den einfachen Mapper das check_date

der richtige key ist und das Format nach

http://wiki.openstreetmap.org/wiki/Key:check_date

YYYY-MM-DD sein sollte.

Ich gebe die Hoffnung nicht auf, dass sich die Experten für etwas eindeutig entscheiden und so den einfachen Mapper nicht weiter verunsichern.

Gruß aus Bietigheim-Bissingen

Die Nutzung des ISO-Formates YYYY-MM-DD ist eindeutig und verständlich.

Indem du die änderst :wink:

Hier https://josm.openstreetmap.de/wiki/Presets ist eigentlich alles beschrieben (Links am Anfang).

Gruss
walter

“Da muss ich mal durch den Translator laufen lassen …”
Schaue es mir trotzdem auch mal an - nur geht es dann nicht “schnell”.
Gruß Gerd

Eindeutig ist es nur, wenn niemand einen Fehler macht. Wenn jemand den ersten Februar 2003 als 2003-01-02 schreibt, dann hat er einen Fehler gemacht … aber wir haben die falschen Daten und kein Programm kann sie als solche erkennen.

Schreibt er dagegen

2003-FEB-01 oder
2003-01-FEB oder
FEB-01-2003 oder
FEB-2003-01 oder
01-FEB-2003 oder
01-2003-FEB

so wird nie ein falsches Datum erkannt und Qualitätssicherungstools können alle 5 fehlerhaften
Fassungen anmeckern und sogar automatisch reparieren.

Nun ja, nur in den ersten 12 Tagen eines Monats :). Das ISO-Format läßt zudem eine einfache zeitliche Sortierung (respektive Größenvergleich zu) ohne das man rechnen muss. Und zudem braucht man sich nicht mit 2017-十二月-03, wenn es ein Japaner geschrieben hat, herumschlagen :).

Das ist ja das Schöne an der Sache: Der Editor oder Prüfprogramme können sofort den Fehler melden, denn zulässig sind nur die ersten drei Buchstaben des englischen Monatsnamens. :slight_smile:

@weide
Klar, wenn ich auf Zahlen verzichte, verzichte ich auf Zahlendreher,
dafür handele ich mir andere Schwierigkeiten ein, welche die ISO 8601 mit dem numerischen Format vermeiden will.

Klar kann ich mich auf den Standpunkt stellen,
dass Qulitätssicherung ganz unten anfängt, und man erstmal alles hinterfragen muss:
“ISO, EN, DIN - sind die wirklich kompetent, wissen die überhaupt worum es geht?”

Aber ich kann damit natürlich auch Entscheidungsprosesse sabotieren:
“Ist die Erde wirklich rund? ist die Erderwärmung tatsächlich menschengemacht?”

An vergleichbaren Ecken von OSM ist die ISO 8601 Notation übrigens usus:
http://wiki.openstreetmap.org/wiki/Key:start_date
Sollte jetzt hier ein neues “OSM-QS-Datumsformat” entwickelt werden, auf das die Welt gewartet hat,
dann bitte auch die andern betroffenen OSM-Wiki Seiten anpassen - Danke.

Welche Schwierigkeiten sind das denn?