OverpassTurbo für Dummies

hurdygurdyman wrote:

Zeige mir nodes mit einer bestimmten key/value-Kombination, die auf oder in der Nähe eines ways mit einer bestimmten key/value-Kombination liegen.

Das benutzen wir in Lüneburg zur Qualitätssicherung ÖPNV. Das kann man wohl recht einfach auf andere Fragen anpassen, indem man key/value und Entfernung anpasst:

[out:json][timeout:25];
{{geocodeArea:lüneburg}}->.searchArea; // Nur hier suchen wir ...
(
node["public_transport"="platform"](area.searchArea);
way["public_transport"="platform"](area.searchArea);
)->.a; // ... nach Bushaltestellen ...
node["public_transport"="stop_position"](area.searchArea); // und nach stop_position ...
(
node(around:50.0)["public_transport"="platform"];
way(around:50.0)["public_transport"="platform"];
); // ... und schauen dann nach, ob es bei letzteren im Umkreis von 50 Metern eine Bushaltestelle gibt.
(.a; - ._;); // Spannend sind die Bushaltestellen, die keine stop_position in ihrer Nähe haben
out meta;

Das geht bestimmt galanter. Ich habe ich mir das mal aus gefundenen Versatzstücken zusammengeklebt und es scheint zu funktionieren

EDIT: Links, die man bookmarken sollte: (möglichst die dt. Versionen verlinkt, tw. gibt es bessere engl. Varianten)
http://blog.openstreetmap.de/blog/2014/ … rpass-api/
http://wiki.openstreetmap.org/wiki/DE:O … uage_Guide
http://wiki.openstreetmap.org/wiki/DE:O … elsammlung
http://overpass-api.de/index.html
http://stackoverflow.com/questions/tagged/overpass-api

Wir haben in Lüneburg POI-Seiten im Wiki, wo wir overpass-Abfragen eingebaut haben: http://wiki.openstreetmap.org/wiki/L%C3 … POI/Museen.

Zumindest eine Teilantwort kann ich bieten:

way["highway"="primary"]({{bbox}});
node(w)->.b;

node["highway"="traffic_signals"]({{bbox}})->.t;

node.b.t;

out;

http://overpass-turbo.eu/s/7kK
Diese Abfrage gibt alle Ampeln auf Wegen mit highway=primary aus.

Edit:
Ups, da war Swen schneller.

Swen Wacker wrote:

...
Das benutzen wir in Lüneburg zur Qualitätssicherung ÖPNV. Das kann man wohl recht einfach auf andere Fragen anpassen, indem man key/value und Entfernung anpasst:
...
Das geht bestimmt galanter. Ich habe ich mir das mal aus gefundenen Versatzstücken zusammengeklebt und es scheint zu funktionieren
...

Scheint gut zu funktionieren 🙂
Somit wirst du heute Abend lobend in meinem Nachtgebet erwähnt (, das übrigens an sämtliche Götter aller Religionen dieser Welt gerichtet wird. Sicher ist sicher...)

Find ich toll, diesen thread.
Hatte auch schon überlegt einen zu eröffnen.

Ich versuche mich schon eine Weile an einer Abfrage für ways mit nur einem node. Ich krieg es einfach nicht hin.

Kann mir hier vielleicht jemand helfen?

Danke im voraus und Grüße

Rainer

Edit: typo

surveyor54 wrote:

ways mit nur einem node.

Ein way ist eine Linie, besitzt also - sag ich jetzt mal als Nichtmathematiker ganz locker und in der Hoffnung, mich nicht zu blamieren :-) - wenigstens zwei Punkte (nodes). Einen way mit einem node kann es also nicht geben. Du meinst was anderes? EDIT: Etwa Wege ohne Tags? http://wiki.openstreetmap.org/wiki/DE:O … ags_finden

er meint vermutlich sowas:
<way id=1001>
<nd ref=1002/>
</way>
soweit ich weiß wird das nicht auf API Ebene validiert sondern die Editoren müssen das prüfen.

Eifach mal 'ne gute Idee solch ein Thema zu öffen. Es gibt bestimmt nicht wenige, die sich damit befassen möchten.

http://wiki.openstreetmap.org/wiki/DE:O … aggt_wurde

Dürfte mit anderen Kategorien machen, was Du suchst oder könnte ein Ansatz sein.

Swen Wacker wrote:

surveyor54 wrote:

ways mit nur einem node.

Ein way ist eine Linie, besitzt also - sag ich jetzt mal als Nichtmathematiker ganz locker und in der Hoffnung, mich nicht zu blamieren :-) - wenigstens zwei Punkte (nodes). Einen way mit einem node kann es also nicht geben. Du meinst was anderes? EDIT: Etwa Wege ohne Tags? http://wiki.openstreetmap.org/wiki/DE:O … ags_finden

In OSMI gibt es doch den Fehler "single node in way", da man hier oft nicht weiß, ob der Fehler schon behoben ist, wollte ich hier ein Abfrage basteln.

Wegabschneider wrote:

Eifach mal 'ne gute Idee solch ein Thema zu öffen. Es gibt bestimmt nicht wenige, die sich damit befassen möchten.

+1

Das ist ein guter Einstieg sich damit endlich mal zu beschäftigen und die ganzen "dummen Fragen" zu stellen 😎
Ich bin dabei!

Stefan

surveyor54 wrote:

In OSMI gibt es doch den Fehler "single node in way", da man hier oft nicht weiß, ob der Fehler schon behoben ist, wollte ich hier ein Abfrage basteln.

Zu mindestens in D räumt doch Wall-E auf: http://wiki.openstreetmap.org/wiki/User … thanize1NW

Sven

Moin!

interessant wäre eine Abfrage aller Relationen mit keinem oder nur einem Element.

Jan

Swen Wacker wrote:

EDIT: Links, die man bookmarken sollte

Da fehlt die momentan einzige halbwegs aktuelle/vollständige Doku: http://wiki.openstreetmap.org/wiki/Over … verpass_QL

surveyor54 wrote:

Ich versuche mich schon eine Weile an einer Abfrage für ways mit nur einem node. Ich krieg es einfach nicht hin.

Das geht aktuell nicht. Die Abfrage in einer BBOX liefert nicht mal diese 1-Knoten-Wege zurück, also kann man auch nicht weiter suchen danach.

Lübeck wrote:

Relationen mit keinem oder nur einem Element.

Kein Element geht auch nicht (lässt sich nicht über bbox einschränken, da keine Geometrieinfos vorhanden, gesamter Planet absuchen braucht zuviel Speicher).
Ein Element lässt sich manuell aus der Liste herausfinden: http://overpass-turbo.eu/s/7ll -> nur auf "Daten" ist was zu sehen, die Karte bleibt leer.

couchmapper wrote:

surveyor54 wrote:

Ich versuche mich schon eine Weile an einer Abfrage für ways mit nur einem node. Ich krieg es einfach nicht hin.

Das geht aktuell nicht. Die Abfrage in einer BBOX liefert nicht mal diese 1-Knoten-Wege zurück, also kann man auch nicht weiter suchen danach.

Da kann ich lange probieren.

Danke

Ich hätte da in meiner Eigenschaft als ahnungsloser Nichtprogrammierer mal wieder einen Fall für die Overpass-Turbo-Power-User.

Geht folgende Abfrage?
Gesucht werden zwei ways (unterschiedliche ID), die an einem gemeinsamen node miteinander verbunden sind und bei denen das value für einen vorgegebenen key identisch ist.
Ein Beispiel:
Zwei aufeinander folgende way mit key "turn:lanes" haben ein identisches value wie z.B. "through|sharp_right".

Einzige Variable wäre somit der key.
Ganz toll wäre es, wenn man auch zwei oder mehr keys vorgeben könnte, die dann jeweils beliebige, aber auf beiden zusammenhängenden ways identische keys haben.

Habe ich mich unklar genug ausgedrückt?

Nahmd,

hurdygurdyman wrote:

Gesucht werden zwei ways (unterschiedliche ID), die an einem gemeinsamen node miteinander verbunden sind und bei denen das value für einen vorgegebenen key identisch ist.
Ein Beispiel:
Zwei aufeinander folgende way mit key "turn:lanes" haben ein identisches value wie z.B. "through|sharp_right".

Soll dabei sowas herauskommen?

Gruß Wolf

Moins,

Lübeck wrote:

interessant wäre eine Abfrage aller Relationen mit keinem oder nur einem Element.

Es gibt zur Zeit 22846 Relationen ohne Element und 189242 Relationen mit nur einem Element. Außerdem 6404 Wege mit nur einem Knoten.

Gruß Wolf

Edit: URL

Netzwolf wrote:

Es gibt zur Zeit 22846 Relationen ohne Element

Sollte diese Relationen - wenn man diejenigen rausfilterte, die in den letzten Woche bearbeitet wurden (man also glauben könnte, da könnte jemand vorhaben, sie wieder mit Elementen zu füllen) - maschinell gelöscht werden?

Netzwolf wrote:

Nahmd,

hurdygurdyman wrote:

Gesucht werden zwei ways (unterschiedliche ID), die an einem gemeinsamen node miteinander verbunden sind und bei denen das value für einen vorgegebenen key identisch ist.
Ein Beispiel:
Zwei aufeinander folgende way mit key "turn:lanes" haben ein identisches value wie z.B. "through|sharp_right".

Soll dabei sowas herauskommen?

Gruß Wolf

Hallo Auswertungs-Guru 🙂
Eine schöne Liste ist das. Jedoch schwebt mir etwas vor, was ich flexibel mit keys füttern kann und das Ergebnis dann auf einer Karte sehe. turn:lanes war nur ein Beispiel. Die Abfrage soll zur Suche von unnötig oder versehentlich geteilten way dienen. Überflüssigerweise zerlegte building oder andere closed ways wären auch damit auffindbar.

Trotzdem Danke für deine Liste.

Netzwolf wrote:

Lübeck wrote:

interessant wäre eine Abfrage aller Relationen mit keinem oder nur einem Element.

Es gibt zur Zeit 22846 Relationen ohne Element und 189242 Relationen mit nur einem Element....

Dazu folgende Frage: Wie weiß ich, ob eine Relation, welche ich (in Potlatch*) geleert habe, doch noch existiert? In einem konkreten Fall habe ich zwei Relationen eines Wanderwegs ("Hasenstabweg") in die größte bereits vorhandene dritte Relation integriert. Im RelationsAnalyzer werden die beiden Relationen dann als gelöscht angezeigt. Ist dem tatsächlich so? (...dass Potlatch einen geleerten Container löscht oder bleibt eine Relationsleiche zurück?)

Cepesko

• bitte keine Kommentare á la: Muddu JOSM verwenden 🤣
  

Nahmd,

cepesko wrote:

In einem konkreten Fall habe ich zwei Relationen eines Wanderwegs ("Hasenstabweg") in die größte bereits vorhandene dritte Relation integriert. Im RelationsAnalyzer werden die beiden Relationen dann als gelöscht angezeigt. Ist dem tatsächlich so? (...dass Potlatch einen geleerten Container löscht oder bleibt eine Relationsleiche zurück?)

Du kannst Deine Relation live in der OSM-DB anschauen. Da findet sich der Link zum Änderungssatz. Und der listet 5 geänderte Relationen und die gelöschte Relation #1578958.

Wenn Du eine weitere Relation angefasst hast, egal ob nur geändert oder gelöscht, müsste das in einem älteren Changeset erfasst sein; Du kannst die Versionen der Hasenstabweg-Relationen durchgehen und die jeweiligen Changesets prüfen oder einfacher Deine Changesets durchblättern.

Die Relation muss in einen CS auftauchen, und da kannst Du schauen, ob sie gelöscht ist.

Gruß Wolf

Nahmd,

Netzwolf wrote:

Es gibt zur Zeit 22846 Relationen ohne Element

Swen Wacker wrote:

Sollte diese Relationen - wenn man diejenigen rausfilterte, die in den letzten Woche bearbeitet wurden (man also glauben könnte, da könnte jemand vorhaben, sie wieder mit Elementen zu füllen) - maschinell gelöscht werden?

Ich hatte gute Laune und hab verspätet Christkind gespielt und Wünsche erfüllt. Ohne Hintergedanken. Automatisches Löschen (ohne anschauen der Tags) halte ich für nicht angebracht.

Ich hab die Liste überarbeitet und zu "type" noch die Eltern-Relationen ("~in"), "name", "note" und den letzten Bearbeiter ("~user") ergänzt. Ich denke, zumindest die eigenen Schandtaten kann man guten Gewissens bereinigen.

.oO( und hab mich gleich zweimal erwischt. Und gleich gefixt. )

Gruß Wolf

Edit: neue URL hinterlegt

Hallo Wolf,

Netzwolf wrote:

Ich hatte gute Laune und hab verspätet Christkind gespielt und Wünsche erfüllt. Ohne Hintergedanken.

Vielen Dank für die Liste... jetzt sehe ich endlich die leeren Reltionen, die ich vor allem in meiner Anfangzeit produziert habe... Nachdem ich die ersten beiden manuell gesichtet und gelöscht hatte... verzichte ich glaube ich auf ein weiteres löschen... Ich werde sie vielmehr nach und nach wieder mit Daten füllen...

bedankt sich Sven

Swen Wacker wrote:

Spannend sind die Bushaltestellen, die keine stop_position in ihrer Nähe haben

Finde ich garnicht spannend - ist völlig OK. Es darf Haltestellen mit beiden Angaben und welche ohne Platform und welche ohne Halteposition geben. PTv2 verlangt nur, dass die Dinger in den Relationen vorkommen, wenn sie vorhanden sind. Auch sind die alten Tags durch PTv2 nicht aufgehoben worden; es ist also nach wie vor völlig OK, wenn da ein Node mit nur highway=bus_stop auf oder neben der Straße ist. (Nicht OK ist es, wenn beide gemappt sind und alle beide highway=bus_stop haben. Zwei highway=bus_stop sind zwei Haltestellen. Das hat aber nichts mit PTv2 zu tun.)

Es gibt riesige Probleme im OSM-ÖPNV (allein in NRW komme ich auf rund 30000 Fehler). Da würde ich solche Sachen vielleicht für 2020 einplanen. :-)

Nix für ungut
Weide

Weide wrote:

Es gibt riesige Probleme im OSM-ÖPNV (allein in NRW komme ich auf rund 30000 Fehler).

Offtopic: Das wäre doch mal was für eine Wochenaufgabe: Tagging von ÖPNV-haltestellen und stop_area-Relationen. (Linien-Routen und ähnliches würde ich wegen der Menge an Arbeit ausgrenzen)

mueschel wrote:

Das wäre doch mal was für eine Wochenaufgabe

Den Gedanken ist verlockend... Die Reparatur ist aber schwieriger als die Fehlersuche und die Reparatur fremder Sachen ist schwieriger als die Reparatur eigener Sachen. Bei eigenen Sachen muss man nur eine richtige Möglichkeit kennen ... bei fremden Sachen alle.

Eine Beispiel für die Schwierigkeit der Reparatur: Ein Node kommt in einer Route mit der leeren Rolle vor und die Route hat public_transport:version=2. Das ist ganz einfach falsch. Soweit der leicht zu findende Fehler. Jetzt die Reparatur: Ist es wirklich eine PTv2-Relation? Vielleicht ist es falsch, dass public_transport:version=2 in der Relation steht. In PTv1-Routen wäre die leere Rolle völlig OK.

Weide

Weide wrote:

Es gibt riesige Probleme im OSM-ÖPNV (allein in NRW komme ich auf rund 30000 Fehler). Da würde ich solche Sachen vielleicht für 2020 einplanen. :-)

Zunächst denke in den Dimensionen einer beschaulichen Mittelstadt in Norddeutschland mit etwa 350 Bushaltestellen, einem Dutzend innerstädtischer Linien und vielleicht zwei Dutzend Überlandlinien, die in den umliegenden Landkreis führen. Da können die beiden der lokalen Mapper, die sich für ÖPNV interessieren, die Latte schon mal höher legen :-)

Weide wrote:

Es darf Haltestellen mit beiden Angaben und welche ohne Platform und welche ohne Halteposition geben.

Mmh. Ich will Dir das gern glauben. Das beschlossene Proposal sagt, dass stop_position mandatory ist. Fand ich immer logisch, weil eine Bushaltestelle ohne stop_position mir nicht in den Sinn kommen will. Was übersehe ich?

Swen Wacker wrote:

Was übersehe ich?

Dass das "mandatory" sich auf das Tag bezieht., "public_transport=stop_position" darf bei einer stop_position niemals entfallen.

Z.B. darf man ja die route_master-Relation weglassen (einer der PTv2-Fehler, wenn man mich fragt), aber am "type=route_master" steht "mandatory".

Bei zwei einander gegenüberliegenden Wartehäuschen jeweils mit Bank und Blindenleitbelag ist ein Node auf der Straße mit
-highway=bus_stop
-tactile_paving=yes
-bench=yes
-shelter=yes
eigentlich komplett.

public_transport=stop_position wäre noch wünschenswert.

Weitere Hinzufügungen kann man als Detailmapping natürlich machen, aber es "komplettiert" nichts.

Weide

PS: wheelchair=... hab ich jetzt nicht erwähnt. Es gehört eigentlich mit rein, das Tagging ist aber mit meines Wissen noch nicht angegangenen Problemen verbunden.

Weide wrote:

Bei zwei einander gegenüberliegenden Wartehäuschen (...) ist ein Node auf der Straße (...) eigentlich komplett.

Ja, eigentlich. Ich lese PTv2 mit dem Selbstverständnis, dass es einen erstrebenswerten Zustand beschreibt, also einen Fortschritt möchte, der einen vorherigen Zustand ablöst. Dann darf ich PTv2 nicht zurücknehmend lesen. Ansonsten müsste ich mich nicht wundern, wenn niemand PTv2 ernst nimmt.

Wir Bonner haben im September 2014 ein Seminar zur Overpass API veranstaltet. [1]
Als Vortragenden konnten Roland gewinnen, hier sein Skript : http://overpass-api.de/misc/overpass_bonn_2014.pdf

[1] http://wiki.openstreetmap.org/wiki/Bonn … r_bei_ZERA

trekki wrote:

...
Als Vortragenden konnten Roland gewinnen, hier sein Skript : http://overpass-api.de/misc/overpass_bonn_2014.pdf
...

Danke für den Link 🙂
und dafür ,dass du den thread wieder vom PTv2 zurück auf seine eigentliche Bestimmung gebracht hast.

Hallo zusammen,
ich versuche mit Overpass-Turbo eine Karte der Bundesländer zu erzeugen.
Konkret geht es um http://overpass-turbo.eu/s/7Fu.

Meine Schwierigkeit ist, dass ich die beiden POI pro Bundesland (label und admin_centre) nicht angezeigt haben will.
Mit MapCSS kann ich zwar alle Nodes ausblenden:

node␣{␣width:␣0;␣␣␣symbol-size:␣0;␣␣␣fill-opacity:␣0;␣}

Wenn ich aber nur die beiden genannten Nodes ausblenden will gelingt mir das nicht:

node[role=admin_centre]␣{␣width:␣0;␣␣␣symbol-size:␣0;␣␣␣fill-opacity:␣0;␣}

Bei den Relationen ist mir schon aufgefallen, dass man in MapCSS keine Anführungszeichen verwenden darf, man also

relation[name=Baden-Württemberg]␣{fill-color:␣yellow;␣}

schreiben muss und nicht wie in der query-language

{{nominatimArea:"Baden-Württemberg"}}

Gibt es eigentlich eine Debug-Möglichkeit für MapCSS?

Viele Grüße, gridy

Hilft Dir:

relation[boundary=administrative]␣node␣{␣width:␣0;␣␣␣symbol-size:␣0;␣␣␣fill-opacity:␣0;␣}

weiter? (Schmeisst alle Nodes innerhalb der Relation weg)
Ich verstehe Deinen Kommentar nicht ganz:

/*␣So␣kann␣ich␣die␣POI␣ausblenden,␣habe␣damit␣aber␣leider␣alle␣Nodes␣ausgeblendet.␣*/

Du willst noch weitere POI in die Abfrage haben, oder welche Nodes genau meinst Du?

Hallo MKnight,
vielen Dank für die schnelle Antwort. Ja das hilft schon mal sehr. Ich wusste nicht, dass man die Bedinungen auch hierarchisch verknüpfen kann.

Zu

Ich verstehe Deinen Kommentar nicht ganz: ... Du willst noch weitere POI in die Abfrage haben, oder welche Nodes genau meinst Du?

Ich will die POI (also in dem Fall die Haupstädte der Bundesländer) nicht anzeigen, aber ggf. noch weitere Nodes, wenn ich die Abfrage noch erweitere.

Weitere Frage:
Ich habe Deinen Hinweis eingebaut in: http://overpass-turbo.eu/s/7FW. Jetzt sieht es schon ganz gut aus. Aber scheinbar funktioniert meine Formattierung zum Namen des Bundeslandes nicht:

␣␣text-color:␣green;
text:␣name:de;
text-position:␣center;

Sollte eigentlich den Text in Grün im Zentrum des Gebiets erscheinen lassen, aber die Schrift ist bei mir Schwarz und bei BaWü auch nicht im Zentrum. Scheinbar habe ich da die Anleitung von http://wiki.openstreetmap.org/wiki/MapCSS/0.2 nicht ganz richtig verstanden.
Hast Du eine Idee, wie man das hinbekommt?

Weitere Frage: Ich wollte das ja auf ganz Deutschland ergänzen, aber http://overpass-turbo.eu/s/7FR steigt mir immer wieder aus. Sind da dann zu viele Daten im Spiel oder ist mein Skript falsch?

Viele Grüße, gridy

Hallo Gridy,
du musst auch bedenken, dass mapcss von eigentlich allen Tools nur teilweise unterstützt wird. Siehe dazu die Tabellen im Wiki unter Vocabulary. Die Implementierung in OverpassTurbo erscheint da zwar nicht, aber hier gibt es ein paar Informationen, was alles unterstützt wird: http://wiki.openstreetmap.org/wiki/Over … rbo/MapCSS

gridy wrote:

Ich wollte das ja auf ganz Deutschland ergänzen, aber http://overpass-turbo.eu/s/7FR steigt mir immer wieder aus.

Ja, das dürften zu viele Daten sein. Wenn ich das mal extrapoliere von einzelnen Bundesländern, dürften es knapp 100 MB Daten sein, die da kommen müssten. Du brauchst allerdings nicht alle Wege und deren Nodes für deinen Zweck. Es reicht die Geometrie der 16 Relationen. (Zumindest sollten es 16 sein... irgendwo ragt das niederländische Groningen aber nach Deutschland rein...)
So bleibt es bei 20 MB in einer verträglichen Zeit.
http://overpass-turbo.eu/s/7FX

Was hast Du eigentlich genau vor? Ich glaub mit overpass(turbo) biste da nich so gut beraten...

mueschel wrote:

gridy wrote:

Ich wollte das ja auf ganz Deutschland ergänzen, aber http://overpass-turbo.eu/s/7FR steigt mir immer wieder aus.

Ja, das dürften zu viele Daten sein. Wenn ich das mal extrapoliere von einzelnen Bundesländern, dürften es knapp 100 MB Daten sein, die da kommen müssten.

Ich hab den timeout bei der Abfrage erhöht und komme auf 20MB. Incl. Browser abschiessen, weil er nich mehr reagiert hat.

Ich möchte herausfinden, welche Bus-Relationen (route=bus) in einem Gebiet nicht Mitglied einer Master-Relation (route_master=bus) sind.

Wie bekomme ich mit overpass heraus, ob eine Relation (nicht) Kind einer Master-Relation ist?

Habe ich einen taktisch unklugen Zeitraum (Wochenende) für diese Frage gewählt? Ich hoffe: ja und erlaube mir deshalb, die Frage noch einmal in Erinnerung zu bringen.

Da wäre ich auch schon wieder mal:
ich möchte die wege mit der Rolle "from" bzw. "to" der "relation=restriction" mit verschiedenen Farben anzeigen lassen. Soweit bin ich schon mal:
[out:json];
(rel["type"="restriction"];>;);
out skel;

{{style:
...

Wie gehts nach style weiter?

hurdygurdyman wrote:

ich möchte die wege mit der Rolle "from" bzw. "to" der "relation=restriction" mit verschiedenen Farben anzeigen lassen. Soweit bin ich schon mal:
Wie gehts nach style weiter?

Mapcss kann das hier:

relation[type=restriction]␣way[role=to]␣{color:red;}

Overpass Turbo scheint das aber nicht zu unterstützen.

mueschel wrote:

...
Mapcss kann das hier:

relation[type=restriction]␣way[role=to]␣{color:red;}

Overpass Turbo scheint das aber nicht zu unterstützen.

Danke, dann eben nicht 🙁

Ich beschäftige mich mal wieder mit den Fahrspuren und Qualitätssicherung. Für Autobahnen ist das ja noch gut machbar, wie mueschel z.B. hier:
http://forum.openstreetmap.org/viewtopi … 25#p477425
und MKnight in dieser Sammlung:
https://wiki.openstreetmap.org/wiki/Use … che_Fehler
zeigen.
Auch mueschels lane Visualizer hilft da http://osm.mueschelsoft.de/cgi-bin/render.pl

Problematisch wird es jedoch spätestens dort, wo wir auch Fahrradspuren haben, weil lanes=* blöderweise etwas unglücklich nur die Spuren für den motorisierten Verkehr zählt. An Stellen wie diesen:
https://www.openstreetmap.org/way/326338169
kommt man da ganz schnell ins Schleudern, wenn man auswerten will, ob alle *:lanes-Varianten vollständig erfasst wurden. cycleway=lane hilft da auch nicht.
Die einzige näherungsweise Lösung wäre, die verschiedenen *:lanes:* je Richtung zu checken, ob bei allen die gleiche Anzahl an "|" (Langstrichen) vorhanden ist.
Wenn man zuerst prüft, ob überhaupt Fahrradspuren erfasst sind, indem man bicycle:lanes:* sucht, könnte man bei ways ohne diese mit der Anzahl aus lanes bei oneway=yes oder sonst aus lanes:* arbeiten. Damit könnten wir doch zumindest eine größere Teilmenge "erschlagen" 🤔
Farbliche Hervorhebung von ways mit bicycle:lanes:* könnte dann markieren, wo Handarbeit durch Analyse der tags am way erforderlich wird.

Ich bitte um Lösungsvorschläge für overpass-turbo.

Am einfachsten wäre natürlich, wenn wir mit lanes die Anzahl aller Spuren erfassen würden. Aber dafür ist der Zug wohl abgefahren 🙄

Swen Wacker wrote:

Ich möchte herausfinden, welche Bus-Relationen (route=bus) in einem Gebiet nicht Mitglied einer Master-Relation (route_master=bus) sind.

Wie bekomme ich mit overpass heraus, ob eine Relation (nicht) Kind einer Master-Relation ist?

Ich denke so:

rel({{bbox}})[route=bus]->.all;
rel[route_master=bus](br.all);
rel[route=bus](r);
(␣.all;␣-␣._;␣);
out;

Erklärung je Zeile:
1. Ermittle alle Relationen im aktuellen Kartenfenster, die vom Typ route=bus sind, speichere das Ergebnis nach .all
2. Ermittle alle Parent-Relationen von .all, die vom Typ route_master=bus sind
3. Ermittle aus dieser Liste von route_master-Relationen wieder alle Child-Relationen vom Typ route=bus. Dies sind nun alles Routen, die Teil eines Masters sind.
4. Bilde die Differenz aus .all und dem Ergebnis aus 3. (ermittelt also alle Routen, die nicht Teil der Menge aller Routen, die einen Master-Parent haben, sind)

Achim

Danke, Achim!

Hallo,

bevor ich mir einen Wolf suche, vielleicht hat einer der Spezis hier ja eine Idee.

Ich sortiere mit Overpass Elemente in verschiedene Variablen ein: ->.Teilmenge
Dann gebe ich verschiedene Variablen aus und möchte diese in verschiedenen Styles dargestellt haben. Gibt es dafür eine Möglichkeit? Das naheliegende nodes.Teilmenge geht jedenfalls nicht. Durch Filtern der Tags lassen sich die Elemente nicht bei der Ausgabe sortieren, da es Überschneidungen gibt.

Happy mapping,

Marc

zorque wrote:

Dann gebe ich verschiedene Variablen aus und möchte diese in verschiedenen Styles dargestellt haben. Gibt es dafür eine Möglichkeit?

Hast Du eine (möglichst auf minimum reduzierte) Beispielabfrage?

Hallo,

zorque wrote:

Dann gebe ich verschiedene Variablen aus und möchte diese in verschiedenen Styles dargestellt haben. Gibt es dafür eine Möglichkeit?

Nein, das geht leider nicht. Schon im XML/JSON/CSV Ergebnis der Overpass API lässt sich nicht mehr erkennen, aus welcher Variablen die Daten ursprünglich stammen.

Gruß,
mmd

Hallo

MKnight wrote:

Hast Du eine (möglichst auf minimum reduzierte) Beispielabfrage?

stimmt, hätte ein Beispiel vorbereiten sollen. Sorry, beim nächsten Mal dann.

mmd wrote:

Nein, das geht leider nicht. Schon im XML/JSON/CSV Ergebnis der Overpass API lässt sich nicht mehr erkennen, aus welcher Variablen die Daten ursprünglich stammen.

schade, genau das habe ich befürchtet.

Gibt es vielleicht irgendwo ein Beispiel, wie man 2 Abfragen gemeinsam darstellen kann? Habe bisher nichts gefunden

Schönes Wochenende!

zorque wrote:

Gibt es vielleicht irgendwo ein Beispiel, wie man 2 Abfragen gemeinsam darstellen kann? Habe bisher nichts gefunden

Meinst Du sowas: http://overpass-turbo.eu/s/8Zd ?

Moin, ich kann nach Objekten suchen, wo ich letzter Bearbeiter bin, Beispiel: http://overpass-turbo.eu/s/97y
Nun suche ich eine Abfrage wo ich mich als letzten Bearbeiter AUSSCHLIESSEN kann. (Die Frage gabs schonmal irgendwo, aber ich finde sie nicht.)
Jemand ne Idee?

Hallo,

das sollte so funktionieren: http://overpass-turbo.eu/s/97z

Ansatz: Alle Knoten mit opening_hours im Suchbereich ermitteln (Bearbeiter spielt dabei keine Rolle) und davon die Knoten mit letzten Bearbeiter MKnight abziehen.

Gruß,
mmd

Sehr schön, danke.

Ich schon wieder. Ich würde jetzt gern 2 oder mehr User ausschliessen. Bisschen mit der Abfrage rumprobiert, laufe ich immer in Fehler rein.
Gibt's da eine Möglichkeit?
Edit: Ah habs. Kreative Klammersetzung ist gefragt:

((way(area.searchArea)["tag"="value"];
-
way(user:"userx")(area.searchArea)["tag"="value"];)
-
way(user:"usery")(area.searchArea)["tag"="value"];

);

Nachtrag: Ich hab mir mit der Abfrage was zurechtgestrickt, um Pseudoreverts zu finden und ich bin positiv überrascht. Bisher hab ich immer zufällig (zufällig=aus Versehen über kaputtes remapping gestolpert) nebenbei irgendwelchen Müll gefunden und nun hab ich auf 25% gezielte Stichproben ausschliesslich Datenverbesserungen gefunden.

hat eigentlich schon mal jemand eine wiki angelegt mit den meistgesuchten abfragen? hier im forum findet doch keiner was.

jepp, siehe Examples und unten bei More den Verweis auf Beispielsammlung

Gibt es es schon. Was hindert Dich daran, dort wertvolle Beispiele zu ergänzen?

Im Wizard wird als Beispiel tourism=museum in Vienna angegeben. Dies im Wizard eingegeben ergibt aber nur die Fehlermeldung:

Unter␣dem␣folgenden␣Suchbegriff␣konnte␣kein␣Eintrag␣gefunden␣werden:

Vienna

Ging das mal oder liegt das an mir? Was ist das Problem?

Bei mir klappt das. Scheint wohl nur ein temporäres Problem gewesen zu sein?

Mist, jetzt seh ich es selber. Das hat mit HTTPS Everywhere zu tun. Wenn man das deaktiviert bzw. blockt wohl die Anfrage zu OpenStreetMap.org. Wenn man dies deaktiviert, denn funktioniert da auch alles. Kann man ja also schauen ob man das im overpass turbo anpassen kann?

TSM1904 wrote:

Das hat mit HTTPS Everywhere zu tun.

Sollte ab jetzt wieder auch mit aktivem HTTP-Everywhere im Firefox funktionieren (siehe ticket).

Ja super, scheint zu funktionieren. Danke! 🙂

Wie gebe ich im Wizard denn ein, wenn ich nach einem Objekt schaue, dem etwas fehlt. Was muss ich bspw. eingeben wenn ich ein Kino (amenity=cinema) ohne Namensangabe (name=*) suche? Bisher konnte ich das irgendwie noch nicht rausfinden, müsste aber doch möglich sein!?

TSM1904 wrote:

Wie gebe ich im Wizard denn ein, wenn ich nach einem Objekt schaue, dem etwas fehlt. Was muss ich bspw. eingeben wenn ich ein Kino (amenity=cinema) ohne Namensangabe (name=*) suche? Bisher konnte ich das irgendwie noch nicht rausfinden, müsste aber doch möglich sein!?

Kein Plan, wie man das im Wizard macht, vlt hilft Dir das weiter: http://overpass-turbo.eu/s/9Dh Wenn Du was anderes oder woanders suchst, einfach modifizieren ... hab ich grad auch gemacht.

TSM1904 wrote:

Wie gebe ich im Wizard denn ein, wenn ich nach einem Objekt schaue, dem etwas fehlt.

amenity=restaurant and cuisine is null hat bei mir funktioniert...

amenity=cinema and name!=* in meinem Fall also. Danke für die Hinweise.

amenity=restaurant and cuisine!=* in Lüneburg z.B.

Upps. Zweiter nach TSM1904 :-)

amenity=cinema and name!=* geht auch.

(Ausgehend von https://www.openstreetmap.org/note/350108 )

Ich hab mir die Abfrage vom Startbeitrag mal dahingehend abgewandelt, dass die mir Ampeln auf Nicht-Einbahnstrassen und ohne traffic_signals:direction auswirft.
Leider wirft die mir so diversen Beifang; im unteren Bereich auf dem Steinweg rechts (und links nochma bisschen komplizierter).
Wie kann ich zusätzlich Ampeln ausschliessen, die einzeln auf einer Kreuzung stehen?

Also ich suche nur Ampeln, wo die realen Positionen gemappt sind, nicht die einfache Variante mit einer Ampel pro Kreuzung.

Edit: Link angepasst.

Kann mir jemand sagen, wie man sich die Anzahl der Treffer einer Anfrage anzeigen lassen kann?

Am Ende ein "out count" anstelle von out meta, out skel oder was auch immer du benutzt.

Naja, als Beispiel würde ich gerne die Anzahl der Windmühlen im Landkreis Sömmerda ausgeben lassen. Also gebe ich im Wizard ein:

man_made=windmill␣in␣"Landkreis␣Sömmerda"

So bekomme ich die Karte mit 6 Punkten raus. Unten rechts in der Karte ist dann zwar was von Nodes (53) und Ways (3), usw. die Rede, aber das ist nicht die Zählweise die ich haben will. Ändere ich an dem durch den Wizard vorgeschlagene Abfrage das out skel qt durch out count, dann bekomme ich in der Karte nur noch 3 Windmühlen angezeigt (das ist ja aber falsch), dies falsche Ergebnis bekomme ich aber auch nicht angezeigt. Also einfach das out count scheint nicht zu funktionieren.

TSM1904 wrote:

Ändere ich an dem durch den Wizard vorgeschlagene Abfrage das out skel qt durch out count, dann bekomme ich in der Karte nur noch 3 Windmühlen angezeigt (das ist ja aber falsch),

Möglicherweise ist das sachlich (unvollständig gemappt) falsch, inhaltlich gibt es eben nur je 3 (traditionelle) Windmühlen als Nodes/Ways in dem Bereich. Der Output von Overpass(turbo) ist also richtig.

Hallo,

out count kann von overpass turbo gar nicht mehr auf der Karte angezeigt werden, da die Antwort keine Koordinaten mehr enthält.
Auch die Anzeige unten rechts auf der Karte berücksichtigt die Ausgabe von out count nicht!

Die folgende Query ermittelt die Zahl der Wege/Knoten/Rels im Suchbereich:

[out:json][timeout:25];
{{geocodeArea:Landkreis␣Sömmerda}}->.searchArea;
(
node["man_made"="windmill"](area.searchArea);
way["man_made"="windmill"](area.searchArea);
relation["man_made"="windmill"](area.searchArea);
);
out␣count;

Ein Ergebnis wird nur im Data-Tab angezeigt, den man dazu nach Ausführung der Query erst öffnen muss.
Demnach gibt es 3 Wege und 3 Knoten mit besagtem Tag.

{
"count":␣{
"total":␣6,
"nodes":␣3,
"ways":␣3,
"relations":␣0,
"areas":␣0
}

Wem das nicht gefällt, der ist mit out geom; evtl. besser bedient: http://overpass-turbo.eu/s/afR - dort zeigt Turbo unten rechts 3 Knoten/3 Wege an und zeigt alle POIs auch auf der Karte.

Gruß,
mmd

Das mit der Reparatur-Info hat mich ein wenig irritiert, aber ja, so komme ich nun zu einem Ergebnis. Danke schön.

@TSM1904,

weshalb brauchst du dafür eine Overpassabfrage ?
Für den LK Sömmerda reicht eine Hand zum zählen und du hättest immer noch einen Finger frei 😎 🤣 😎

wer sich mal mit komischen Keys auseinandersetzen möchte, sei folgende Abfrage empfohlen:
(Findet alle Nodes (in Deutschland), deren Key mit Großbuchstaben A bis Z beginnt und deren Atribute nicht leer sind)
😎

[out:xml][timeout:100];
{{geocodeArea:de}}->.searchArea;
// gather results
(

node[~"^[AZ]"~"."]//({{bbox}});
(area.searchArea);

);

out meta qt;

Hmm, muss man dafür wirklich overpass nutzen? Okay, wenn man unbedingt auf DE eingrenzen möchte, dann vielleicht. Ich habe mir aber auch einfach mal per http://taginfo.openstreetmap.org/keys sortiert nach key ausgeben lassen. Dass fängt schon mit Leerzeichenbehafteten Keys an, dann kommen lustigen Zahlen (31h=Hirtengrund) und weiter geht's dann mit den Großbuchstaben Keys wie z.B. "Bezeichnun", "Bezahlmethode", "Betreiber" lustig weiter 😉

Nachtrag: und eigentlich müsstest du bewusst großgeschriebene Tags (z.B. FIXME) ausschließen

Harald Hartmann wrote:

ch habe mir aber auch einfach mal per http://taginfo.openstreetmap.org/keys sortiert nach key ausgeben lassen.

Wenn taginfo eine Art bbox hätte und nicht stets die ganze Welt durchwühlen würde, könnte man sich prima "seine" Stadt vornehmen und nach typos oder Wechstabenverbuchslern suchen.

Swen Wacker wrote:

Wenn taginfo eine Art bbox hätte und nicht stets die ganze Welt durchwühlen würde, könnte man sich prima "seine" Stadt vornehmen und nach typos oder Wechstabenverbuchslern suchen.

Viele Länder haben ihr nationales Taginfo, das diese Statistiken für das jeweilige Land anzeigt. http://wiki.openstreetmap.org/wiki/Taginfo/Sites

Für Deutschland hat halt bisher noch keiner eins aufgesetzt.

Hallo!
Könnte mir jemand eine Abfrage erstellen, die nodes und ways ausspuckt, die einen Bindestrich im addr:housenumber-Tag haben?
Sowas ist bei uns recht verbreitet und ich will da ran.
Beispiel: http://www.openstreetmap.org/way/114465374

http://forum.openstreetmap.org/viewtopic.php?id=27151

Funktioniert das: http://overpass-turbo.eu/s/aoO ?

MKnight wrote:

http://forum.openstreetmap.org/viewtopic.php?id=27151

Is ja'n Ding! 😛

Beiden Danke!

Mal wieder eine Anfrage von mir. Ich habe zwar kaum Hoffnung, dass dies vollumfänglich möglich ist, aber das werdet ihr mir schon sagen können. Und zwar, ist es möglich:
a.) mir anzeigen zu lassen, wo es ein Gebäude gibt (wahlweise mehrere, zwei, drei, vier) und im Umkreis von 5km kein weiteres
b.) und als Zusatz dazu, wo das landuse=residential oder landuse=farm auf dem das Gebäude steht, komplett innerhalb eines Radiuses von maximal 100m um das Gebäude liegt?

Bzw. etwas ähnlich: ein landuse=residential oder landuse=farm, welches nicht größer als 2000m² ist und in dessem Umfeld mind. 2km kein weiteres liegt?

Das geht nicht oder? (Sollte ich dafür lieber ein QGIS für Dummies-Thread eröffnen? 😉)

TSM1904 wrote:

Das geht nicht oder?

Ich würde für alle genannten Fragen ausnahmslos auf PostGIS (vielleicht auch QGIS) zurückgreifen wollen.

Die Argumente:

a) Zählen (im Rahmen von Vergleichen) wird nicht unterstützt; das mit dem Umkreis von 5km kein weiteres wäre noch irgendwie mit foreach machbar, allerdings extrem langsam
b) Um herauszufinden, ob ein Gebäude in einem landuse=residential oder landuse=farm steht, müssten diese ein "name"-Tag tragen, sonst funktioniert is_in nicht. Damit würde es nicht möglich sein, zunächst überhaupt alle relevanten Gebäude zu ermitteln.
c) Größen von Flächen messen bzw. Beziehungen mit kleiner/größer gleich geht ebenfalls nicht.

Geschlossene Wege suchen, geht sowas?

MKnight wrote:

Geschlossene Wege suchen, geht sowas?

Nein, sowas geht heute nicht.

Was ich mir vorstellen könnte, was geht: ich suche in einem Gebiet nach einem Wert der größer, gleich oder kleiner ist als ein anderer. Wie suche ich also bspw. Parkplätze mit einer Kapazität von gleich oder mehr als 100 Stellplätzen?

Wie um Himmelswillen gewöhne ich Overpass turbo die Anzeige der "Kreise" ab, wenn das entsprechende Objekt für die aktuelle Zoomstufe zu klein ist? Ich meine diese hier: https://wiki.openstreetmap.org/wiki/Ove … bo#Map_key.

Hintergrund: ich lade eine (Wander)Relation (Rennsteig) mit den Wegen und färbe surface entsprechend per mapcss ein.
PS: Wenns dann gut aussieht würde ich das natürlich noch in die Overpass Beispielsammlung aufnehmen.

[out:json][timeout:25];
//␣gather␣results
(relation(398874);way(r);>;);out;

{{style:
way:tained{}
way:placeholder{}
/*␣without␣*/
way
{␣color:red;␣width:16;␣}
way[surface]
{␣color:blue;␣width:8;␣}

/*␣paved␣*/
way[surface=paved]
{␣color:red;␣opacity:1;␣}
way[surface=asphalt]
{␣color:black;␣}
way[surface=cobblestone],
way[surface=paving_stones],
way[surface=paving_stones:30],
way[surface=paving_stones:20]
{␣color:grey␣}
way[surface=concrete]
{␣color:lightgrey;␣}
way[surface=wood]
{␣color:yellow␣}

/*␣unpaved␣*/
way[surface=unpaved]
{␣color:red;␣dashes:3,9;␣opacity:1;␣}
way[surface=compacted]
{␣color:darkgrey;␣dashes:4,12;␣}
way[surface=gravel]
{␣color:grey;␣dashes:4,12;␣}
way[surface=fine_gravel]
{␣color:white;␣dashes:4,12;␣}
way[surface=ground],
way[surface=earth],
way[surface=dirt]
{␣color:brown;␣dashes:4,12;␣}
way[surface=grass]
{␣color:green;␣dashes:4,12;␣}
way[surface=sand]
{␣color:yellow;␣dashes:4,12;␣}
}}

hat sich erledigt ... man sollte halt auch bis zum schluss lesen 😎

Circles with a red filling represent ways or polygons that are too small to be displayed normally (to switch this off and show the small feature instead: Settings → Map → "Don't display small features as POIs.").

Harald Hartmann wrote:

hat sich erledigt ... man sollte halt auch bis zum schluss lesen 😎

Circles with a red filling represent ways or polygons that are too small to be displayed normally (to switch this off and show the small feature instead: Settings → Map → "Don't display small features as POIs.").

Ähem, ich seh da keine Änderung.

Also ich habe, nachdem ich das aktiviert habe, durchaus einen Unterschied gesehen. Leider liefert das recurse down aber auch Nodes der Ways zurück, z.B. Ortseingangsschilder und diese werden dann sehr wohl wieder als Kreis (POI) dargestellt 🤔

Ach ja, hier noch der Link zur Overpass-turbo Query ... habe ich auch mal ins deutsche Surface-Tag und in die deutsche Overpass-Turbo Beispielsammlung mit aufgenommen.

Wenn Overpass Turbo keine Tags zu den Nodes geliefert bekommt, dann gibt es auch keinen Grund Kreise anzuzeigen:

relation(398874);way(r);out;>;out␣skel;

"Wege mit allen Details, bei den zugehörigen Nodes nur die Koordinaten"

Apropos surface in einer Relation. Ich suche gerade alle Wege innerhalb einer Relation die (k)ein surface haben. Das sollte mit ner geringfügigen Umschreibung der aktuelle (Ab)Frage zu machen sein? Ich seh nur grad den Wald vor lauter Bäumen nicht.

Hallo:

für surface-Tag: [surface]
für kein surface-Tag: [surface!~"."]

Beides kommt unmittelbar nach dem way(r):

relation(398874);way(r)[surface!~"."];out;>;out␣skel;

- damit werden also die Wege in der Relation einfach weiter eingeschränkt.

Gruß,
mmd

Kuhl, thx.

Nachtrag: sehr hybsche Abfrage übrigens um Radrouten zu verbessern.
Nachtrag 2: Auf nen schönen Bug gestossen, oder ich hab schon wieder ein Brett vorm Kopf: wenn ich die Abfrage in Josm lade, holt josm die Relation nicht mit. oO
Kann das jemand bestätigen anhand: http://overpass-turbo.eu/s/aVP ?

Die Relations-angaben holt Josm für (alle geladenen) Abschnitte nach, wenn ich an einem einzelnen Teilstuck via Strg+Alt+↓ daten neu/zusätzlich hole. Wo ist da der Fehler verborgen? Overpass(/-Turbo), Josm oder Brett vorm Kopf?

Also ich hab zwischen relation und way einfach noch ein ;out meta; eingefügt und dann kommt die relation mit ... aber irgendwie muss ich mich glaube ich mal näher/genauer mit overpass beschäftigen ... aktuell ist das bei mir mehr try and error 😄

Ah, ok, funzt nun. (nach mehrmaligen rumprobieren...)

TSM1904 wrote:

Was ich mir vorstellen könnte, was geht: ich suche in einem Gebiet nach einem Wert der größer, gleich oder kleiner ist als ein anderer. Wie suche ich also bspw. Parkplätze mit einer Kapazität von gleich oder mehr als 100 Stellplätzen?

Hat da niemand eine Idee oder geht das schlicht einfach nicht?

TSM1904 wrote:

TSM1904 wrote:

Was ich mir vorstellen könnte, was geht: ich suche in einem Gebiet nach einem Wert der größer, gleich oder kleiner ist als ein anderer. Wie suche ich also bspw. Parkplätze mit einer Kapazität von gleich oder mehr als 100 Stellplätzen?

Hat da niemand eine Idee oder geht das schlicht einfach nicht?

Geht mehr oder weniger umständlich mit Trick: Man kann Werte auf reguläre Ausdrücke testen. Unter der Annahme, dass niemand führende Nullen hinschreibt, wäre beispielsweise >= 100 eine Zahl, die aus mindestens drei Ziffern besteht. Demzufolge wäre dort die Abfrage (Beispiel):

["capacity"~"^[0-9]{3,}$"]

Schwieriger wird es, wenn man nicht gerade die Dezimalgrenze als Unterscheidungsmerkmal hat. Beispielsweise die gleiche Abfrage mit >= 350 - der vorher noch angezeigte Parkplatz südlich der Reeperbahn mit 310 Plätzen ist dann nicht mehr in der Treffermenge (Beispiel):

["capacity"~"^([0-9]{4,}|[4-9][0-9]{2}|3[5-9][0-9])$"]

Der erste Zeil deckt alle mindestens 4-stelligen Zahlen ab, der zweite Teil alle Zahlen von 400 bis 999, der dritte Teil alle Zahlen von 350 bis 399.

Das kann man natürlich auch umgedreht mit Zahlen < 350 machen (Beispiel):

["capacity"~"^([0-9]{1,2}|[1-2][0-9]{2}|3[0-4][0-9])$"]

Der erste Teil deckt hier alle ein- und zweistelligen Zahlen ab, der zweite Teil alle Zahlen von 100 bis 299, der dritte Teil alle Zahlen von 300 bis 349.

Derartige Vergleiche mit Fließkommazahlen sei als Übung dem geneigten Leser überlassen. 😉

Super, danke Kontinentalverschieber, das haut hin und so halbwegs verstehe ich das sogar. Hat mir geholfen.