OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2017-11-30 16:27:03

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,107
Website

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 … on=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

Last edited by geri-oc (2017-11-30 16:34:29)

Offline

#2 2017-11-30 17:31:25

RoterEmil
Member
Registered: 2016-10-09
Posts: 303

Re: Qualitätssicherung

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

Offline

#3 2017-11-30 17:47:07

Jo Cassel
Member
Registered: 2015-12-02
Posts: 460

Re: Qualitätssicherung

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

Offline

#4 2017-11-30 17:50:23

Yokr
Member
Registered: 2015-10-31
Posts: 520

Re: Qualitätssicherung

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

Offline

#5 2017-11-30 17:59:23

glglgl
Member
Registered: 2014-06-19
Posts: 373

Re: Qualitätssicherung

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>


glglgl

Offline

#6 2017-11-30 18:55:39

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,107
Website

Re: Qualitätssicherung

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.

Offline

#7 2017-11-30 19:10:25

Lübeck
Member
Registered: 2009-02-17
Posts: 2,574

Re: Qualitätssicherung

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


Android 2.2 & 4.1.1 / Webkit 3.1 / PC: Win7 64bit

Offline

#8 2017-11-30 19:21:41

lowlander
Member
From: Uppenberg
Registered: 2017-08-02
Posts: 55

Re: Qualitätssicherung

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


Für die DatenRenderer, nicht für die RendererDaten! (-:

Offline

#9 2017-12-01 09:14:45

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,107
Website

Re: Qualitätssicherung

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.

Offline

#10 2017-12-02 09:22:37

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,107
Website

Re: Qualitätssicherung

Noch eine Frage:

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

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

Last edited by geri-oc (2017-12-02 09:23:41)

Offline

#11 2017-12-02 09:56:17

Weide
Member
Registered: 2009-04-05
Posts: 1,308

Re: Qualitätssicherung

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.

Offline

#12 2017-12-02 10:12:25

ghostrider44
Member
Registered: 2015-09-06
Posts: 65

Re: Qualitätssicherung

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

Offline

#13 2017-12-02 10:22:00

lowlander
Member
From: Uppenberg
Registered: 2017-08-02
Posts: 55

Re: Qualitätssicherung

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.

Last edited by lowlander (2017-12-02 10:25:00)


Für die DatenRenderer, nicht für die RendererDaten! (-:

Offline

#14 2017-12-02 11:22:38

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,992
Website

Re: Qualitätssicherung

geri-oc wrote:

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

Indem du die änderst wink

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

Gruss
walter

Online

#15 2017-12-02 11:53:11

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,107
Website

Re: Qualitätssicherung

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

Offline

#16 2017-12-02 17:23:58

Weide
Member
Registered: 2009-04-05
Posts: 1,308

Re: Qualitätssicherung

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.

Offline

#17 2017-12-03 20:27:13

user_5359
Member
From: Königswinter
Registered: 2008-12-25
Posts: 252
Website

Re: Qualitätssicherung

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

Offline

#18 2017-12-04 08:48:27

Weide
Member
Registered: 2009-04-05
Posts: 1,308

Re: Qualitätssicherung

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

Offline

#19 2017-12-05 12:34:23

Jo Cassel
Member
Registered: 2015-12-02
Posts: 460

Re: Qualitätssicherung

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

Offline

#20 2017-12-05 12:52:35

MKnight
Member
Registered: 2012-08-01
Posts: 1,826

Re: Qualitätssicherung

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?


gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften

Offline

#21 2017-12-05 13:03:59

GeorgFausB
Member
From: Probstei, Schleswig-Holstein
Registered: 2008-10-14
Posts: 1,442

Re: Qualitätssicherung

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

Offline

#22 2017-12-05 13:06:02

kreuzschnabel
Member
From: Taunusstein ± 1300 km
Registered: 2015-07-03
Posts: 5,451

Re: Qualitätssicherung

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


Avatar-Bild von Elaine R. Wilson, www.naturespicsonline.com, CC-BY-SA 3.0
Mitmachen? Klar! Mein OSM-Tutorial auf Deutsch

Offline

#23 2017-12-05 15:22:25

seichter
Member
Registered: 2011-05-21
Posts: 2,624

Re: Qualitätssicherung

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

Offline

#24 2017-12-06 07:44:42

Weide
Member
Registered: 2009-04-05
Posts: 1,308

Re: Qualitätssicherung

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

Offline

#25 2017-12-06 08:26:17

miche101
Member
Registered: 2008-12-16
Posts: 662
Website

Re: Qualitätssicherung

Zum Eingeben vom Datum... könnte auch der Editor ein wenig helfen wink 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

Last edited by miche101 (2017-12-06 08:29:04)

Offline

Board footer

Powered by FluxBB