[out:json][timeout:25];
// gather results
(
// query part for: “~"name:*"~Munich”
node[~"name:.*"~"Munich"]({{bbox}});
);
// print results
out body;
>;
out skel qt;
Toll 
select distinct id
from (select id, value "name", localname, level, (each(tags)).*
from boundaries) foo
where (key = 'name' or key like 'name:%')
and key != 'name:suffix'
and value ilike 'munich'
;
id
--------
181652
62428
(2 Zeilen)
Zeit: 4506,648 ms
Geht, aber einfach war das net, gell? Gibt es nicht irgendwo eine Wiki-Seite mit Overpass-Abfragen? Bau diese “Perle” doch bitte ein.
Gruss
walter
Stimmt natürlich… Ich werde mal schauen, ob das mit verträglicher Performance in Overpass läuft.
Mein Hintergrund ist der, dass ich keine möglicherweise fehlerhaften Keys in Timbuktu korrigieren möchte, sondern nur die in meiner “Homezone” und/oder in DACH. Bin da mal in Polen auf die Fresse gefallen, die sich da einig waren lokal irgendwas Neues einführen zu müssen.
Tja, da habe ich leider ein Problem. Die Overpass-Query wird leider zu lang um sie direkt an Overpass-Turbo übergeben zu können und ich bekomme es nicht hin, dass OT meine Query lzw-komprimiert-base64-encoded annimmt, obwohl das eigentlich gehen sollte.
Hallo mueschel,
seit gestern ist in Deiner Auswertung noch die Spalte Editor hinzugekommen. Wenn ich dort auf J für JOSM klicke, erscheint immer ein neues Fenster mit den Buchstaben OK, das JOSM als Antwort auf das Fernsteuer-Kommando antwortet. In den meisten Anwendungen, die JOSM über einen Klick aufrufen, wird diese Antwort nicht angezeigt - wäre hier auch ganz vorteilhaft. Wie das geht, steht in diesem Posting (Die Frage in #1104, die Antwort (hiddenIframe) in #1106).
Franz
Danke für den Tipp, ist auch schon eingebaut!
Hallo mueschel,
Dein hidden iFrame ist verloren gegangen! Wenn ich auf das (J) in der rechten Spalte clicke, bekomme ich wieder eine neue Seite im Browser, in der nur OK steht. Auch im Quelltext finde ich keine Definition, was bei target=“hI” angezeigt werden soll.
Franz
Beim Hochladen sind anscheinend die letzten 15 kByte verloren gegangen, die Tabelle wird auch nicht richtig beendet im Code… Habe es nochmal manuell auf den Server geschoben und im Durchlauf morgen sollte es auch wieder / immer noch passen.
Da ist für mich auch die API gefragt - Keys abseits von a bis z, underscore und Doppelpunkt sind immer eine schlechte Idee (denn was nützen viele menschenlesbare Infos, die aber nicht automatisiert verwertbar sind?). Und allmählich dürften auch geügend Keys beisammen sein, so dass man darüber nachdenken darf neue Keys nur noch nach Diskussion und expliziter Aufnahme zu erlauben. Das mögliche Erfinden eigener Keys (und - je nach Key - auch der Values) war mal eine gute und notwendige Sache, mittlerweile ist das IMO unterm Strich aber kontraproduktiv. Leider.
Viele sind aber auch schnell wieder weg (Schreibfehler) - geht das nicht eigentlich automatisch?
biuilding → building
+1
Und wenn man dann auch noch “variable Keys” - ein Widerspruch in sich - zulässt, wird es chaotisch.
Aber ich wiederhole mich 
Gruss
walter
Im Prinzip schon, siehe Wall-E.
Bei nur wenigen Einträgen sind die aber von Hand schneller beseitigt, als man braucht, um eine neue Regel zu erstellen und zu testen.
In der heutigen Liste der fehlerhaften Keys (Link siehe Beitrag #1) kamen einige Keys mit dem Zeichen 0x7F vor, die sich über Overpass-Suche nicht direkt finden lassen.
Hier die Liste mit den Keys, die das Zeichen 0x7F enthalten:
addr:%7Fcountry
addr:%7F%7F%7F%7F%7Fstate
admin_l%7Fevel
disused:%7F%7Frailway
disus%7Fed:railway
landuse%7F
serv%7Fice
s%7Fource:name
s%7Fo%7Furce
%7Faddr:full
%7Fdestination:ref
%7Fentrance
%7Fleisure
%7Fman_made
%7Fphone
%7Ftracktype
%7Fwikipedia
%7F%7F%7Falt_name
%7F%7F%7Floc_name
%7F%7F%7Fsource:description
%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7F%7Fbuilding:levels
Wie komme ich zu den IDs, über die ich diese Objekte in JOSM öffnen und korrigieren kann?
Franz
Falls Du die Objekte einzeln anschaust (und überlegst, was genau gemeint war und es entsprechend korrigierst),ist das ok. Falls Du aber eher Suchen-und-Ersetzen-mässig vorgehen möchtest, ist es ein “mechanischer Edit”, der zuvor diskutiert werden müsste.
Bei einem mechanischen Edit könnte beispielsweise das Problem auftreten, dass ein Objekt ein “landuse=forest” und ein “landuse%7F=foobar” hat, und jemand, der nicht hinschaut, verpasst dem Objekt dann “landuse=foobar” und überschreibt damit die vermutlich richtigen Daten.
Ausserdem - egal ob mechanisch oder von Hand repariert wird - wäre auch eine Ursachenforschung interessant: Ist es immer der gleiche User oder immer der gleiche Editor? Dann liegt vielliecht ein systematischer Fehler vor, den man beheben muss, weil er sonst immer wieder auftaucht.
Zu Deiner eigentlichen Frage: Wenn Du weisst, dass ein bestimmtes Tag ein an einem bestimmten Tag (…) neu hinzukam, kannst Du von planet.openstreetmap.org das Tagesdiff dieses Tages herunterladen und darin suchen, das müsste noch gut handhabbar sein.
Bye
Frederik
Taginfo lief am 29. und 30. nicht, und am 1. waren diese Tags in der Auswertung drinnen. In den daily diffs 325, 326 und 327 finde ich allerdings nichts. Auf der Taginfo-Seite kann man in der Tag-Liste nach filtern - das sind von den values her völlig unterschiedliche Dinge aus verschiedenen Ländern.
Die Diffs habe ich auch durchsucht und nichts gefunden. Auch mittels Overpass-Turbo finde ich keine Ergebnisse für z.B. “serv\u007fice”. Daher vermute ich, dass diese 7F erst nach dem Lesen der Diffs und vor dem / beim Zusammenbau dieser Liste für die Webseite hinzugekommen sind - also in unserer Datenbank nicht enthalten sind .
Edit:
Wenn ich das Zeichen %7F als ersten und einzigen Buchstaben bei Taginfo ins Suchfeld eingebe, bekomme ich die Liste aller Zeilen aus Beitrag #28, die mit dem %7F beginnen. Wenn ich nun einige Zeilen anklicke, bekomme ich in der Überschrift des neuen Tabs des Browsers die gleiche Anzahl an %7F, wie in der Liste.
Nun stellt sich die Frage, wie kommen wir an die IDs dieser Objekte, wenn Overpass-Turbo dieses Zeichen nicht verarbeitet?
Franz
Und es gibt sie doch:
http://www.openstreetmap.org/node/3188718399
Gefunden über den bei Taginfo hinterlegten Wert und einer bbox auf Kiev.
Wurde schon vor einiger Zeit in die Datenbank hinzugefügt. Wahrscheinlich hat Taginfo die vorher nicht angezeigt und jetzt gab’s ein Softwareupdate.
In Australien habe ich zufällig auch eine Fläche (Insel) mit 3x %7F am Anfang des Keys und 2x %7F am Anfang des Values gefunden. (“source:description” als Suche in Overpass-Turbo (ohne die %7F am Anfang)).
Edit:
In Südamerika den loc_name mit 3x %7F am Anfang.
%7Fwikipedia ist hier.
%7Fdestination:ref ist hier.
Franz
Ich kann diese maroden Tags in meiner SQL-DB (Full Planet) auch nicht finden. Stimmt die Auswertung den wirklich?
Übrigens: HEX 7F ist das Ascii DEL - das wäre merkwürdig, wenn es das in die OSM-Rohdaten DB in UK geschafft hätte.
Gruss
walter
ps: nachher scanne ich mal meine Diffs, die habe ich ab 2015 online bei mir liegen.