Qualitätssicherung

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. 😉

Jo Cassel wrote:

"(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.

Vermutlich nicht.

<rant>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.</rant>

Jo Cassel wrote:

"(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.

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

geri-oc wrote:

Ich würde mich bei einer Festlegung für
(109x) check_date:collection_times=YYYY-MM-TT
auch für (516x) check_date:opening_hours oder (14x) check_date:xmas:day_date oder check_date:* entscheiden

Yokr wrote:

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.

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

geri-oc wrote:

Eventuell kann man
check_date=YYYY-MM-TT
für die Prüfung "aller" Angaben nutzen.

Ein Vorschlag, dem ich uneingeschränkt zustimme. 🙂

Ich habe die deutsche WIKI-Seite ergänzt:
https://wiki.openstreetmap.org/w/index. … id=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:

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

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=*)

glglgl wrote:

<rant>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.</rant>

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

Weide wrote:

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

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

geri-oc wrote:

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

Indem du die änderst 😉

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

lowlander wrote:

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

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.

Weide wrote:

lowlander wrote:

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

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.

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 🙂.

user_5359 wrote:

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. :-)

@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.

Jo Cassel wrote:

dafür handele ich mir andere Schwierigkeiten ein, welche die ISO 8601 mit dem numerischen Format vermeiden will.

Welche Schwierigkeiten sind das denn?

MKnight wrote:

Jo Cassel wrote:

dafür handele ich mir andere Schwierigkeiten ein, welche die ISO 8601 mit dem numerischen Format vermeiden will.

Welche Schwierigkeiten sind das denn?

Berechne einfach mal eine Differenz ... oder ob ein Datum in einem Bereich liegt ...

MKnight wrote:

Jo Cassel wrote:

dafür handele ich mir andere Schwierigkeiten ein, welche die ISO 8601 mit dem numerischen Format vermeiden will.

Welche Schwierigkeiten sind das denn?

Das numerische Format YYYY-MM-DD hat den unbestreitbaren Vorteil, dass eine alphanumerische Sortierung (normal von links nach rechts sortierend) auch gleich eine chronologische ergibt.

--ks

GeorgFausB wrote:

Berechne einfach mal eine Differenz ... oder ob ein Datum in einem Bereich liegt ...

So trivial ist das auch mit Ziffern nicht, sobald es über die Bereichsgrenzen (12, 28-31) geht.
Für JAN - DEC ist die Umwandlung in Zahlen vergleichsweise trivial (Enumeration).
Viele Anwendungen wie Excel machen das sogar intern automatisch.
In Programmen ist damit auch die Sortierung kein Problem, bleibt nur das rein alphanumerische Sortieren als Nachteil dieses Ansatzes.

Ich bin zwar sonst auch für international genormte Angaben, aber die Drei-Buchstaben-Angabe hat für mich den Charme der besseren Interpretierbarkeit durch Menschen (und dadurch geringere Fehlerrate).

Jo Cassel wrote:

@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?"

Glaubst Du wirklich, dass ich das will?

Ich benutze das ISO-Format oft und seit langem. Dabei habe ich aber auch die Erfahrung gemacht, dass in internationalen Projekten die in verschiedenen Kulturen üblichen Reihenfolgen von Tag, Monat und Jahr immer wieder für typische Fehler in solchen Angaben sorgen. Diese Probleme kann man mit einer solchen Notation vermeiden und das funktioniert nach meiner Erfahrung gut. Die automatische Verarbeitung wird dadurch in OSM nicht nennenswert behindert.

PS: :-) Leute, die historische Daten verarbeiten müssen, haben der ISO übrigens vorgeworfen, dass sie nicht gewusst haben was sie da tun :-) Die Festlegung, dass das Jahr mit Vorzeichen geschrieben werden darf, macht nämlich die einfache Sortierbarkeit wieder kaputt. Dass das nur selten vorkommt, ist kein Vorteil ... es ist die Existenzgarantie für getestete aber nicht korrekte Programme. :-)

Zum Eingeben vom Datum... könnte auch der Editor ein wenig helfen 😉 z.B. nicht durch Eingaben... sondern durch Auswahl im Kalender, wie man das aus anderen Programmen, Apps her kennt. Das würde viele Fehler vermeiden.

sowas:
https://h5c3.de/_img/html5-input-date.png

@Weide, Nein, ich glaube nicht, dass Du hier *vorsätzlich* etwas ausbremst, wenn Du jetzt aber, statt Dich mal zu start_date zu äußern, schon mit BC-Daten - für ein check_date(!) - kommst, was soll ich dazu noch sagen? "Facepalm"?-)

@miche101, Eben, bei einem check_date ließe sich (außerdem) auch eine primitive Plausibilitätskontrolle bei der Eingabe realisieren: Liegt das eingegebene check_date länger als (z.B.) eine Woche in der Vergangenheit, dann kann halt nochmal nachgefragt werden ("meinten Sie wirklich...").

survey:date

ist auch so ein Tag... der vom Keypad-Mapper 3 verwendet wird.

( http://wiki.openstreetmap.org/wiki/Key: … uselang=de )

Edit: wurde schon erwähnt 😉