josm/overpass: Nodes+Ways mit Eigenschaft X=Y innerhalb REL Z laden

Moin,

gelegentlich hole ich mir über die Overpass-api Öffnungszeiten in JOSM rein, die in bestimmte Bundesländern liegen.
Für Thüringen und äquivalent andere “kleine” Bundesländer mache ich das so:
Datei->
Adresse öffnen →
hxxp://overpass-api.de/api/interpreter?data=(node(area:3600062366)[“opening_hours”];way(area:3600062366)[“opening_hours”];);(._;>;);out meta;

Das geht ne Weile gut, bis man bei Bundesländern wie Bayern, NRW etc. landet. Dort läuft entweder das Ram (auf overpass) voll oder die Execution-time ist zu kurz. Im IRC wurde mir geraten, das Timeout höher zu setzen, das bringt aber nix wenn das RAM voll is.

Jemand ne Idee, wie ich das auf grössere Bundesländer anwenden könnte OHNE die in zig Landkreise etc aufzudröseln?

https://osm.wno-edv-service.de/boundaries/idx16o.jsp?zoom=8&lat=51.44039&lon=7.66395&layers=0BT&selected=73340_73347_63306_72022_63594

NRW hat 4 Regierungsbezirke mit al5 und Bayern hat 7 al5

Gruss
walter

Ah, das is schon mal ein guter Workaround, danke.

Die Area-Berechnung scheint ziemlich viel Speicher zu benötigen. Mit einer BBOX-Abfrage für BaWü, Bayern, etc. läuft’s dagegen durch (wenn auch ohne exakte Grenze - keine Ahnung, wie wichtig dir das ist).

[bbox:{{bbox}}];(way[“opening_hours”];>;);out meta;

vs.

area[name=“Bayern”]->.area;
way(area.area)[“opening_hours”];out meta;

Mach am besten mal auf GitHub ein Ticket dazu auf unter https://github.com/drolbr/Overpass-API/issues/

Die bbox is nich ganz schlecht (hab ich ne Weile gemacht), holt mir aber entweder zuviel Daten aus anderen Ländern rein oder zuwenig aus .de je nachdem wie man die zieht.
Andere Länder sind wenig optimal, weil ich in josm eine Prüfung durchlaufen lasse und dann zuviele (Öffnungszeiten-)Fehler als Beifang reinbekomme, die ich entweder mangels Sprachkenntnissen oder mangels Recherchemöglichkeiten nicht korrigieren kann oder will. Kurz: es wird unübersichtlich. (Beispiel: http://www.openstreetmap.org/way/133960412 … ok, das is noch eins der einfachereren)

So ganz nebenbei, hast du eine Hausnummer wieviel Nodes das betrifft, als “nicht korrekte” Öffnungszeiten haben? Vielleicht wär das ja auch was für eine Wochenaufgabe, es hört sich zumindest danach an :wink:

Harald, jo, hab ich auch schon drüber nachgedacht, gute Idee.
Gerade eben NRW korrigiert, das waren um die 200 Fehler. (zuzüglich etwa 30-50 komplexere, die ich nicht angefasst habe)

Bayern und Bawü hab ich lang nich angefasst, kommt als näxtes. In den restlichen Bundesländern (die ich mir so 14-tägig etwa dahingehend anschaue), sollten grob übern Daumen etwa 300 einfache Fehler und etwa 1000 komplexere (Monatsranges, ohne Ortskenntnise schwer recherchierbare Tipfehler etc.) zu finden sein.

Kannst/Willst du hier schreiben, was für eine Prüfung das ist und wie du diese ausführst?

PS: Auch wenn es noch nicht spruchreif ist, ich habe mir mal https://github.com/ypid/opening_hours.js gezogen, real_test.js auf geojson von overpass angepasst und mir darüber mal in meine bbox eine Auswertung über korrekte/falsche opening_hours gemacht und sie mir prettified ausgeben lassen.

Habe das Skript noch ein bisschen angepasst und einfach mal mit der im Eingangspost erwähnten Abfrage von Thüringen durchlaufen lassen:


2014-04-08T05:51:36Z [WARNING] http://www.openstreetmap.org/node/671401946 (Mo 14:00-17:00; Tu-Fr 10:00-13:00,14:00-17:00:PH off)
Mo 14:00-17:00; PH <--- (The selector "holiday" was switched with the selector "weekday" for readablitity and compatibiltity reasons.)
Mo 14:00-17:00; PH Tu-Fr <--- (The selector "weekday" was switched with the selector "time" for readablitity and compatibiltity reasons.)
Mo 14:00-17:00; PH Tu-Fr 10:00-13:00,14:00-17:00: <--- (The selector "time" was switched with the selector "holiday" for readablitity and compatibiltity reasons.)
2010-11-27T21:10:13Z [FAILED] http://www.openstreetmap.org/node/850599161 (Mo-Fr 16:00+; Sa -18:00; Su 10:00-12:30,16:00+; Tu off)
2013-10-09T15:04:23Z [FAILED] http://www.openstreetmap.org/node/1411202577 (Mo 08:00-12:00, 14:00-18:00 ?)
2014-08-06T06:09:31Z [FAILED] http://www.openstreetmap.org/node/1411221696 (Mo 08:00-12:00 ?  ?  ?  ?)
2013-01-21T09:04:38Z [FAILED] http://www.openstreetmap.org/node/1411221699 (Mo 08:00-12:00, 14:00-18:00 ?)
2013-06-15T08:42:21Z [FAILED] http://www.openstreetmap.org/node/1417077735 (Mo 08:00-14:00; Tu 12:00-18:00; We 08:00-13:00; Th 12:00-18:00;  Fr 08:00-13:00 ?)
2011-09-07T08:56:47Z [FAILED] http://www.openstreetmap.org/node/1425896788 (Mo-Fr 10:00-19:00 ?  ?  ?  ?)
2013-12-30T20:58:19Z [FAILED] http://www.openstreetmap.org/node/1438209869 (Mo 07:30-12:00, 15:00-18:00 ? ?)
2011-09-26T15:22:14Z [FAILED] http://www.openstreetmap.org/node/1446295839 (Mo 08:00-11:00,14:00-17:00; Tu 08:00-11:00, 14:00-17:00; We 08:00-11:00; Th 08:00-11:00, 14:00-16:00; Fr 08:00-11:00??  ?)
2014-04-10T16:12:08Z [WARNING] http://www.openstreetmap.org/node/2781726478 (Mo 08:00-18:00; Tu 08:00-16:00; We 13:00-18:00; Th 08:00-16:00; Fr 08:00-16:00: PH off)
Mo 08:00-18:00; Tu 08:00-16:00; We 13:00-18:00; Th 08:00-16:00; PH <--- (The selector "holiday" was switched with the selector "weekday" for readablitity and compatibiltity reasons.)
Mo 08:00-18:00; Tu 08:00-16:00; We 13:00-18:00; Th 08:00-16:00; PH Fr <--- (The selector "weekday" was switched with the selector "time" for readablitity and compatibiltity reasons.)
Mo 08:00-18:00; Tu 08:00-16:00; We 13:00-18:00; Th 08:00-16:00; PH Fr 08:00-16:00: <--- (The selector "time" was switched with the selector "holiday" for readablitity and compatibiltity reasons.)
2014-08-04T16:54:42Z [FAILED] http://www.openstreetmap.org/node/2981094225 (auf Anfrage)
2014-08-13T05:24:09Z [WARNING] http://www.openstreetmap.org/node/3013703237 (Mo-Sa 11:00-19:00;So 12:00-18:00)
Mo-Sa 11:00-19:00;So <--- (Bitte benutze die englische Abkürzung "Su" für "so". Could also mean Saturday in Polish .)
2013-12-05T16:48:07Z [FAILED] http://www.openstreetmap.org/way/129213820 (Mo-We 10:00-13:30; Th 10:00-17:00  ?  ?)
2014-05-13T23:25:46Z [FAILED] http://www.openstreetmap.org/way/205679110 (Jan-easter -1 day: 11:00-18:00; easter-Oct: 11:00-20:00; Nov,Dec: 11:00-18:00)
2014-07-21T12:24:59Z [WARNING] http://www.openstreetmap.org/way/293121395 (Fr 15:00-19:00; Sa,Su.PH 14:00-19:00)
Fr 15:00-19:00; PH <--- (The selector "holiday" was switched with the selector "weekday" for readablitity and compatibiltity reasons.)
Fr 15:00-19:00; PH Sa,Su <--- (The selector "weekday" was switched with the selector "holiday" for readablitity and compatibiltity reasons.)

Done :)

2366/2377 (successfully: 99.54 %, unpretty: 23.96 %, with warnings: 0.17 %)
2377 values, 1302 ms (1825.65 n/sec).

Ich nutze den normalen Josm-QA-Check:

  • Nodes und Ways laden (in diesem Falle opening_hours wie ontopic beschrieben)
  • Strg+A
  • Fenster “Prüfergebnisse” (ALT-UMSCHALT+V)
  • Prüfung
    → zeigt mir alle Fehler und Warnungen der geladenen Daten
    Dort bearbeite ich dann alle kaputten Öffnungszeiten aus dem Prüffenster heraus.

Das opening_hours-script (was übrigens (bzw. der Validator davon) auch in die josm-qa-prüfung integriert ist) ist mir bekannt aber ich blicke da leider nicht durch.

Okay, wenn ich das mit derselben Ausgangbasis nehme, zeigt mir die Prüfung von JOSM nur 3 Fehler und 1 Warning an.
Und ja, dass JOSM wohl auch das opening_hours-script nutzt habe ich ebenfalls gelesen, aber dann erklärt es die Abweichung nicht ganz. Weil wie man in meiner Auswertung sieht, sind bei einigen Öffnungszeiten diese ? (also irgendwelche nicht darstellenbaren Zeichen/Whitespaces) im Feld, die JOSM anscheinend vorher trimmed. :roll_eyes:

Josm trimmed die nicht, sondern man sieht sie einfach nicht. (Wenn man bearbeitet, sieht man es dann…) Auf OSM.org übrigens auch nicht.
Ist möglicherweise ein Fehler im Validator von Josm, dass er die übersieht; zumindest Thüringen hab ich mind. einmal die Woche aufm Schirm und diese Sachen bisher nicht wahrgenommen. (Wobei man dazu auch ehrlicherweise sagen muss, dass es streng genommen keine Fehler sind)
Kannst Du 'nem Dau - also mir - erklären, wie Du “Dein” Script aufgerufen (und modifiziert) hast?

Habe mal nachgeschaut: Bei n1425896788 ist hinter der letzten ‘0’ ein Leerzeichen, ein U+00a0 “NO-BREAK SPACE” und dann dreimal zwei Leerzeichen denen jeweils ein U+00a0 folgt. Also “nur” Whitespace, für den JOSM hoffentlich eine eigene Warnung ausgibt.

Apropos Leerzeichen: Du hast da auch eins zu viel: “Polish .)” :wink:

Ich werde es versuchen, aber um ein paar technische Dinge bzw. Voraussetzungen wird man wohl nicht ganz rum kommen. Dazu würde ich aber das Skript nochmal überarbeiten und es hoffentlich noch ein bisschen “DAUgerechter” zu machen. Werde mich dann hier nochmal dazu äußern.

Guten Abend,

die Idee mit der Wochenaufgabe hatte ich natürlich auch schon :D. Ich würde aber vorschlagen, dass wir damit warten bis das ganze noch ein wenig einfacher geworden ist. Ich arbeite aktuell an einer Integration in das qat_script.

Ich habe in letzter Zeit ein paar zusätzliche Funktionen und tests eingebaut, die noch nicht in JOSM sind: https://github.com/openstreetmap/josm/blob/mirror/data/validator/opening_hours.js. Daran wird es wohl liegen.

Du hast die Statistikausgabe verschönert :slight_smile: Hab ich gleich mal übernommen.

Danke für den Hinweis, aber in meinen Quellen ist der Fehler nicht vorhanden. Eventuell ein Encoding Problem mit “…”.

@Harald: Ich beantworte die Frage mal hier …

Da es dabei um die Entwicklung von opening_hours.js geht. Ich teste die Bibliothek mit allen Werten in OSM. Das runterladen von taginfo ist für diesen Fall die bessere Wahl. Es gibt ein anderes Skript, was mehr in deine Richtung geht (siehe dazu diese Anfrage auf GitHub).

Okay, also wenn ypid an einer besseren Integration in das qat-script arbeitet, werde ich mein Skript erstmal nicht weiter verfolgen, da ich das Skript zwar einfach machen könnte, aber definitiv nicht so “DAUgerecht” wie eine gute Integration in JOSM wäre und eben die technischen Voraussetzungen (git, node.js) nicht ganz ohne sind, v.a. auf einem Windows System … und deshalb auch das Encoding Problem mit “…”, das mag die cmd.exe gar nicht :laughing:

Ja, das habe ich auch gesehen, aber ich habe das unter small scale erwähnte regex_search.py auch nach 2 stunden (auf windows) nicht zum Laufen gebracht, da du auf osm-site verweist und ich das irgendwie nicht gut installiert bekomme.

Werde mir wohl dochmal ein Ubuntu oder sowas aufsetzen müssen…

So so :stuck_out_tongue:

regex_search.py benutzt ein Python Wrapper Paket um mit opening_hours.js zu sprechen. Das Paket wird eigentlich über ein git submodule eingebunden, muss dann aber noch wie im README beschrieben eingerichtet werden (make installDependencies).

Immer eine gute Idee. Das Ubuntuusers Wiki hat mir damals den Einstieg sehr vereinfacht.

Zusätzlich würde ich abwarten, bis das aktuelle Script in der JOSM-internen QA-Prüfung drin is. Das Qat-script hat zum einen nicht jede/r und zum anderen hat die josm-interne Prüfung bei einfachen eindeutigen Fehlern eine halbautomagische Korrektur.

Für die, die von Öffnungszeiten nicht genug bekommen gibt es jetzt die Lösung: http://www.openstreetmap.org/user/ypid/diary/23719

(Auch mit Hinblick auf die eventuelle Wochenaufgabe, damit sich keiner über mangelnde Arbeit beschweren kann :wink: )

Sollte in der nächsten Version integriert sein: https://josm.openstreetmap.de/ticket/10494

Ich habe demletzt übrigens eine sehr schöne Methode gefunden (irgendwo im Thread weit hinten Fahrspuren mit Richtungspfeilen erfassen; Wochenaufgabe in KW 47/48) Tags innerhalb Regionen zu suchen:
http://overpass-turbo.eu/s/6qc
BUNDESLAND=Bereich wo man suchen möchte, kann auch eine Stadt oder dergleichen sein.
DEINTAG=Zu suchende Eigenschaft
Je nach Bereich ist es sinnvoll,

[timeout:25];

höher zu setzen.

Als Demonstrations-Beispiel Öffnungszeiten fürs Saarland:
http://overpass-turbo.eu/s/6qd