Hallo Gemeinschaft, folgende Frage:
Irgendwie ist es mir “gelungen”, identische Wanderwegweiser in OSM doppelt zu erfassen (mittels ID). Keine Ahnung wie, es ist aber passiert. Heißt: Auf exakt derselben Koordinate 2 guideposts mit den exakt gleichen Tags und Werten und das in mehreren Fällen. Zufällig bin ich später anhand eines Hinweises in ID drüber gestolpert, die allermeisten sind wieder Singles. Das hat mich aber zu der Frage geführt, inwieweit man die mehrfachen Nodes mittels Overpass Turbo ermitteln könnte.
Im Grunde geht es ja darum, guideposts nach ihrer lat und lon zu gruppieren mit Anzahl (count) als Aggregierung und anschließend das Ergebnis zu filtern (count = 2 bzw. allgemeiner > 1)
Folgende Abfrage habe ich letztlich entworfen, jedoch ohne Filter:
{{geocodeArea:Harz}} → .hz;
node[tourism=information]information=guidepost;
for( lat() + “,” + lon())
{
make stat “geopos”=set( lat() + “,” + lon()), count=count(nodes);
out;
}
Als Vorlage diente mir ein Blogbeitrag ( Loop and Group (overpass-api.de))
Ich weiß nicht, wie der count Filter zu formulieren ist. Kann mir jemand von Euch auf die Sprünge helfen?
Die Abfrage liefert 4165 stat nodes zurück, aber nur 3 von denen mit einem count Wert = 2. Die 3 könnten also noch von meinem “Unfall” sein.
Für mich geht’s vor allem auch darum, ein Verständnis für die Sprache zu gewinnen bzw zu erweitern.
Besten Dank schon mal.
Das ist zwar ein anderer Ansatz der keine Statistik erstellt, aber diese Abfrage zeigt dir alle doppelten (oder sehr sehr nahen) Nodes auf Wegweisern an:
Ich würde zuerst hier schauen: Osmose
Allerdings ist da nix bei, möglicherweise hast Du alles schon aufgeräumt oder morgen gg. Mittag trudeln die Fehler neu ein.
Vielen Dank und Du hast recht - Asche auf mein Haupt - ich hätte den Code zur besseren Lesbarkeit formatieren sollen.
Dein Code trifft zwar nicht ganz meine Absicht, “Zwillingsnodes” von guideposts zu ermitteln, ist aber dessen ungeachtet ein interessantes Anwendungsbeispiel. Auf den Harz angewandt, erhalte ich 3 Knoten, die auf den Knoten anderer ways liegen. Aber es sind halt keine guidepost Zwillingsknoten. Trotzdem: Danke für deine Antwort.
Ja, ich hatte gestern die XML Ergebnismenge (4165 Knoten) mittels XPath (//stat[tag[@k=“count”]/@v > 1]) extern noch gefiltert, die 3 (zum Glück nur 3) gefundenen dann gleich gefixt.
Den link zu Osmose kenne ich noch nicht. Ist ja offensichtlich user bezogen. Vielen Dank!
Trotz der 2 bisherigen Antworten, die mir neuen Input gegeben haben, bleibt letztendlich die für mich schon wichtige Frage offen, wie man in Overpass turbo Aggregierungsergebnisse noch filtern kann, also vom Effekt her ähnlich wie in SQL (group by having ). Gibt es dazu irgendwo Beispiele, aus denen man lernen könnte?
Trotz der 2 bisherigen Antworten, die mir neuen Input gegeben haben, bleibt letztendlich die für mich schon wichtige Frage offen, wie man in Overpass turbo Aggregierungsergebnisse noch filtern kann
du kannst doch einfach die Ergebnisse filtern (download und dann filtern)
Das habe ich ja gemacht, weil ich’s in dem Moment nicht besser wusste (siehe Antwort an MKnight), also Overpass Ergebnis als XML ausgeben, Webseite freeformatter - den Xpath Tester aufrufen, XML Ergebnis nach “XPath Tester” kopieren und dort als XPath Expression //stat[tag[@k=“count”]/@v > 1]. Das hats ja dann auch gebracht aber den Weg würde ich eher als quick & dirty ansehen. Schöner wäre es, die gesamte Logik in Overpass Turbo abbilden zu können.
Die müsste meine Abfrage eigentlich auch finden. Bist du sicher, dass es überhaupt noch welche gibt?
Wenn du wirklich nur Guidepost auf Guidepost finden willst, ändere die Abfrage in der for-Schleife zu node(around.gp:0)[information=guidepost] -> .n;
Das liefert mir für den Harz aber keine Ergebnisse.
Du hast recht! Natürlich. Ich hatte ja die 3 gefundenen nodes gelöscht. Habe eben mal einen Zwillingsnode zum Test erstellt. Der wurde nun auch gefunden.
Interessant hierbei ist: Wenn ich den Filter in der “around”-Zeile um das guidepost Kriterium erweitere, läuft Overpass Turbo in einen timeout bei timeout Wert = 300.
Führe ich Deinen Original Code aus, ist Overpass nach ca. 4 Sekunden zurück, hat dann allerdings auch noch den “Beifang” dabei.
… Nach wiederholten Versuchen hat es Overpass auch innerhalb der 300 Sekunden geschafft. Das zusätzliche Kriterium scheint die Performance spürbar zu beeinflussen. Ich denke, man in solch einem Fall auch die zu befragende Fläche so klein wie möglich wählen.
Aber es ist tatsächlich eine Lösungsmöglichkeit!. Top!
Der erste Versuch sieht schon sehr gut aus, daher modifiziere ich nur
möglichst wenig.
Die Abfrage
{{geocodeArea:Harz}}->.hz;
node[tourism=information][information=guidepost](area.hz);
for( lat() + "," + lon())
{
if (count(nodes) > 1)
{
make stat geopos=set( lat() + "," + lon()), count=count(nodes);
out;
}
}
liefert alle “Zwillingsnodes” mit den Tags [tourism=information][information=guidepost]. Weil es davon im
Zielgebiet keine mehr gibt, zur Illustration das Ganze für alle Nodes:
{{geocodeArea:Harz}}->.hz;
node(area.hz);
for( lat() + "," + lon())
{
if (count(nodes) > 1)
{
make stat geopos=set( lat() + "," + lon()), count=count(nodes);
out;
}
}
Ggf. erleichtert die Verwendung von [out:csv] die Weiterverarbeitung:
[out:csv(geopos,count)];
{{geocodeArea:Harz}}->.hz;
node(area.hz);
for( lat() + "," + lon())
{
if (count(nodes) > 1)
{
make stat geopos=set( lat() + "," + lon()), count=count(nodes);
out;
}
}
Den Gebrauch von foreach sollte man möglichst minimieren, da es
prinzipbedingt ziemlich langsam ist.
Verblüffend! Vor allem, weil es verblüffend einfach aussieht. Zeigt aber auch, dass ich noch zu weit weg bin von der Sprache.
Aber ein schönes Beispiel, wie man Aggregierungsergebnisse noch filtern kann.
