OverpassTurbo für Dummies

http://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung#Geb.C3.A4ude.2C_durch_die_ein_Weg_f.C3.BChrt.2C_der_nicht_als_tunnel_oder_covered_getaggt_wurde

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

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.

+1

Das ist ein guter Einstieg sich damit endlich mal zu beschäftigen und die ganzen “dummen Fragen” zu stellen :sunglasses:
Ich bin dabei!

Stefan

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

Sven

Moin!

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

Jan

Da fehlt die momentan einzige halbwegs aktuelle/vollständige Doku: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL

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.

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.

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,

Soll dabei sowas herauskommen?

Gruß Wolf

Moins,

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

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?

Hallo Auswertungs-Guru :slight_smile:
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.

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 :laughing:

Nahmd,

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,

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,

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

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

Nix für ungut
Weide

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)

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

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 :slight_smile:

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?