Datenpunkte filtern und exportieren

Hallo,
was Du vorhast ist mit overpass grundsätzlich alles möglich - Voraussetzung ist aber immer, dass die Objekte auch in OSM erfasst sind...
Erstmal eine Abfrage *in Brandenburg* nach Gebäuden ODER Gebetsorten mit St. Jacobi ODER Sankt Jacobi im Namen (z. B. auch "Kirche St. Jacobi")

http://overpass-turbo.eu/s/10xv

Ist die historic.place-Karte auf OSM-Basis bekannt?
http://gk.historic.place/historische_ob … w313670734

Hallo,

historic=monument sind die "gigantischen" Denkmäler, historic=memorial die "normalen".

Probier mal http://overpass-turbo.eu/s/10xy

Viel Erfolg
Joachim

DD1GJ wrote:

Hallo,

historic=monument sind die "gigantischen" Denkmäler, historic=memorial die "normalen".

Probier mal http://overpass-turbo.eu/s/10xy

Viel Erfolg
Joachim

Ah! Wieder etwas dazu gelernt. Vielen Dank!

Das geht genau in die richtige Richtung.

Gibt es für solche Abfragen auch ein GUI / ein Desktop-Programm, mit welchem man UND- und NICHT-Verknüpfungen abfragen kann?

Also

Gebiet: "Land X"
Objekt: "Denkmal"
Filter: "XY im Namen"
Nicht: "Z im Namen / als Objektbezeichnung"

Also zum Beispiel

Gebiet: Moskau
Objekt: Denkmal
Filter: Lenin (Alle Denkmäler mit "Lenin" im Namen)
Ohne: Gedenktafeln

Eine solche Abfrage sollten dann alle Lenin-Denkmäler im Verwaltungsbereich der Stadt Moskau (nicht des Gebietes Moskau) ausgeben, die keine Gedenktafel für eine Rede, einen Auftritt, einen Besuch, eine Wohnung u.ä. Lenins sind. Damit sollten dann nur Statuen, Büsten, Wandbilder, etc. ausgegeben werden.

Also in meiner einfachen Vorstellung. Ich weiss jedoch nicht, wie gut und feinteilig in der OSM-Datenbank solche Objekte klassifiziert sind.

Gibt es irgendwo eine einfache Tabelle mit den Attributen, mit denen in der OSM-Datenbank Objekte versehen werden können?

So dass ich dann mit Hilfe dieser Tabelle Abfragen wie nachfolgende definieren könnte:

- alle Straßen in Deutschland mit "Marx" in der Bezeichnung
- alle Denkmäler in Deutschland mit "Marx" in der Bezeichnung
- alle Denkmäler in Deutschland mit Errichtungsjahr 1990

Danke für Antworten schon vorab.

Jo Cassel wrote:

Ist die historic.place-Karte auf OSM-Basis bekannt?
http://gk.historic.place/historische_ob … w313670734

Jetzt ja. 😉 Danke!

Was ich suche ist eine Möglichkeit der Abfrage von bestimmten Objekten, die nicht immer historisch sein müssen, da aktuell vorhanden. Also:

- Straßennamen
- Denkmäler
- Museen

aber auch historisch:

- frühere Arbeitslager / KZ-Lager / Gulag-Lager, etc.
- Hinrichtungsorte
- Massengräber

Alles natürlich vorbehaltlich dem Umstand, dass solche Attribute jemals in die OSM-Datenbank eingetragen wurden und nicht nur in speziellen Datenbanken liegen, die nicht öffentlich zugänglich sind.

Diese Objekte würde ich dann gerne als KML/KMZ exportieren und als Layer auf aktuelle Satellitenbilder (z.B. in Google Earth oder Garmin BaseCamp) legen, um den Ort zu visualisieren.

In welche Richtung müsste ich suchen, um zu einem solchen Ergebnis zu kommen?

Danke für Antworten schon vorab.

Zumindest mal für einen Teil deiner Fragen ein paar Hinweise:
Die Abfragesprache mit Overpass Turbo ist schon etwas speziell, aber es gibt auch einen Assistenten, Wizard genannt (Schaltfläche in der grauen Leiste oben). Da kannst du z.B. schreiben

highway=*␣and␣name~Marx␣in␣Brandenburg

highway ist der Schlüssel für alle Straßen und Wege
= ist der Operator "ist gleich"
* steht für alle vorkommenden Werte der Wege; du könntest auch einen bestimmten Wert, z.B. residential angeben, dann werden nur Wohnstraßen selektiert
and ist die Und-Verknüpfung mit der nächsten Abfrage
name ist der Schlüssel für Eigennamen von x-beliebigen Objekten
~ ist der Operator "enthält"
Marx ist hier der gesuchte Namensbestandteil
in Brandenburg gibt den Bereich an, in dem gesucht werden soll. Das ist eine Relation, die ein bestimmtes Gebiet beschreibt; es werden dann die zuvor definierten Abfragen nur in diesem Suchgebiet gemacht. Eine solche Relation muß natürlich existieren, was für Verwaltungsbezirke ziemlich gut erfüllt sein dürfte.

Daraus resultiert dann diese Abfrage.

Wenn man die so generiert hat, kann man sich oft erschließen, wie man die Abfrage abwandeln kann, um seine Suche zu verfeinern.
Kleiner Hinweis hierzu: standardmäßig generiert der Wizard Abfragen mit 25s Timeout; das kann für größere Gebiete zu knapp sein. Wenn eine entsprechende Meldung kommt, den Wert erhöhen und nochmal laufen lassen.

Wenn du nicht weißt, wie ein Objekt von Interesse kartiert ist, d.h. welche Schlüssel mit welchen Werten verwendet werden, um es zu beschreiben, such einfach mal auf osm.org danach, z.B. "KZ-Gedenkstätte". Dann such dir ein passendes Objekt heraus, z.B. https://www.openstreetmap.org/way/150141297; alle Attribute ("Tags") sind aufgelistet und die in blauer Schrift verweisen auf die Wiki-Seiten, die die Verwendung des jeweiligen Attributs beschreiben.

-Rubashov- wrote:

Diese Objekte würde ich dann gerne als KML/KMZ exportieren und als Layer auf aktuelle Satellitenbilder (z.B. in Google Earth oder Garmin BaseCamp) legen, um den Ort zu visualisieren.

In overpass-turbo gibt es einen Reiter "Export", darunter die Option "Speichere/Kopiere als KML".

-Rubashov- wrote:

[...]
Also zum Beispiel

Gebiet: Moskau
Objekt: Denkmal
Filter: Lenin (Alle Denkmäler mit "Lenin" im Namen)
Ohne: Gedenktafeln

Eine solche Abfrage sollten dann alle Lenin-Denkmäler im Verwaltungsbereich der Stadt Moskau (nicht des Gebietes Moskau) ausgeben, die keine Gedenktafel für eine Rede, einen Auftritt, einen Besuch, eine Wohnung u.ä. Lenins sind. Damit sollten dann nur Statuen, Büsten, Wandbilder, etc. ausgegeben werden.

Also in meiner einfachen Vorstellung. Ich weiss jedoch nicht, wie gut und feinteilig in der OSM-Datenbank solche Objekte klassifiziert sind.
[...]

Habe mal analog zur Kirchenabfrage in #2 zunächst diese Abfrage nach historic=memorial erstellt, vgl. dazu die Dokumentation:
https://wiki.openstreetmap.org/wiki/DE: … 3Dmemorial

http://overpass-turbo.eu/s/10Ap

Da ich des Russischen nicht mächtig bin, kann ich nicht wissen, was da konkret rumsteht, die russischen Mapper waren aber so schlau, häufig
subject:wikipedia + subject:wikidata
zu verwenden, damit habe ich in einem 2. Schritt eine Plausibititätsprüfung gemacht, die grün umrandeten Fundstellen beziehen sich mit Sicherheit auf die Person Lenins.

Darauf aufbauend eine 2. Abfrage *nur* nach memorial=statue ODER memorial=bust mit Lenin im Namen
http://overpass-turbo.eu/s/10Aq

Das subject:-Tagging ist eine prima Sache und man könnte auch eine Suchstrategie auf Basis subject:wikidata=Q1394 verwenden, allerdings kann man nicht davon ausgehen, dass überall so sauber getaggt wird...

Vielen Dank für die bisherigen hilfreichen Beiträge.

In den letzten beiden Tagen habe ich mit den verschiedenen Optionen von http://overpass-turbo.eu/ experimentiert. Dabei sind mir als Laien mehrere Dinge aufgefallen:

1. Das Tagging der Objekte in der OSM ist ganz offensichtlich alles andere als konsistent. Mal werden Objekte als "monument", mal als "memorial", mal als "tourism", mal als "artwork" attribuiert. Nun gut. Liegt wohl am Auge des Betrachters, hier desjenigen, der das Objekt in die Datenbank eingetragen hat. Dann muss ich halt mehrere Abfragen durchführen.

2. Als Abfrageinstrument ist http://overpass-turbo.eu/ eher suboptimal. Zum einen ist die Laufzeit für die Abfragen sehr hoch (teilweise mehrere Minuten, je nach Größe des Filters) und zum anderen gibt es recht schnell (nach einigen wenigen Abfragen) eine Sperre der IP als Überlastungsschutz.

Vor diesem Hintergrund stellt sich die Frage erneut, ob es auch eine Möglichkeit gibt, solche Abfragen mit Hilfe eines lokal installierbaren Programms mit GUI und einer lokalen Kopie der OSM-Datenbank durchzuführen. Dies dürfte schneller sein und nicht die allgemeinen Ressourcen so sehr beanspruchen wie Abfragen über http://overpass-turbo.eu/.

In diesem Zusammenhang: Kann es sein, dass das Forum wiederkehrend "hängt", d.h. der Server die Anfragen mit timeout verwirft?

Du kannst osmfilter verwenden, hat allerdings ein CLI und keine GUI.

-Rubashov- wrote:

[...]
1. Das Tagging der Objekte in der OSM ist ganz offensichtlich alles andere als konsistent. Mal werden Objekte als "monument", mal als "memorial", mal als "tourism", mal als "artwork" attribuiert. Nun gut. Liegt wohl am Auge des Betrachters, hier desjenigen, der das Objekt in die Datenbank eingetragen hat. Dann muss ich halt mehrere Abfragen durchführen.
[...]

Ja, das ist mitunter so, wobei mehrfaches-Haupt-Tagging mitunter aus der Sache resultiert, nicht unbedingt ein Fehler ist, und eine Auswertung nicht unbedingt behindert.
Wirklich schlechtes Tagging hat meiner Erfahrung nach 2 Gründe
- mangelhafte Dokumentation, die aber verbessert werden kann und sukzessive verbessert wird
- Fachkräftemangel, den DU lindern könntest ;-)

Bedenke bitte, dass dies hier im Kern ein Freiwilligen-Projekt mit beschränkten Ressourcen ist, viele Probleme sind bekannt und nur jammern hilft da nicht wirklich weiter.

-Rubashov- wrote:

und zum anderen gibt es recht schnell (nach einigen wenigen Abfragen) eine Sperre der IP als Überlastungsschutz.

Deine "Sperre" kannst Du hier einsehen: https://overpass-api.de/api/status

Vor diesem Hintergrund stellt sich die Frage erneut, ob es auch eine Möglichkeit gibt, solche Abfragen mit Hilfe eines lokal installierbaren Programms mit GUI und einer lokalen Kopie der OSM-Datenbank durchzuführen.

Ich würde mir per overpass alle relevanten Daten nach JOSM holen, speichern und dann im lokalen Datensatz rumfiltern.

-Rubashov- wrote:

Vor diesem Hintergrund stellt sich die Frage erneut, ob es auch eine Möglichkeit gibt, solche Abfragen mit Hilfe eines lokal installierbaren Programms mit GUI und einer lokalen Kopie der OSM-Datenbank durchzuführen.

Die leistungsstärkste Lösung für eine solche Anforderung ist, die Daten in eine lokale PostGIS-Datenbank zu importieren (mit osm2pgsql oder auch imposm) und dann auf dieser Datenbank Abfragen durchzuführen. Da kann man dann mit allen Mitteln der SQL-Datenbank arbeiten, ggf. für wiederkehrende Abfragen auch Indexe anlegen, um sie zu beschleunigen und so weiter.

(Was in der Regel nicht geht, ist ein späterer "Weg zurück", als Du kannst nicht Daten in der PostGIS ändern und dann wieder zu OSM hochladen, aber das willst Du ja auch nicht, und es wäre ohnehin aus anderen Gründen problematisch.)

Die PostGIS selbst hat kein GUI, allerdings gibt es mit "pgAdmin" ein allgemeines PostgreSQL-GUI, und man kann auch mit QGIS direkt auf eine PostGIS zugreifen.

Auf diesem Wege nochmals vielen Dank für die bisherigen Tips und Tricks und Hinweise.

In den letzten Tagen habe ich etliche Abfragen durchgeführt. Dabei ist mir neben der zu meinem Bedauern extrem inkonsistenten Attribuierung von Objekten aufgefallen, dass diese nicht einheitlich als Objekte markiert sind, was bei den Abfragen zu Problemen führt.

So sind viele Denkmalanlagen ("monument" / "memorial") kartographisch korrekt als Flächen gezeichnet. Ein Export dieser Objekte als Flächen führt folgerichtig zu Flächenmarkierungen in einer KML-Datei.

Wird dann diese KML-Datei in Programmen wie Google Earth geöffnet, dann werden diese Objekte aber eben auch nur als Flächen angezeigt, nicht als Markierung eines Objektes. Deshalb sind diese Objekte auch regelmäßig nicht als solche bei kleineren Maßstäben in Programmen wie Google Earth zu sehen, da die Flächen zum Teil nur wenige Quadratmeter ausweisen.

Beispiel: Ein Denkmal in Form einer Büste wird als Fläche in OSM markiert, mit 1m2 Größe. Eine andere Büste wird als Ort markiert, nicht als Fläche ausgewiesen. Beide Objekte sind als "historic"="memorial" in der OSM markiert, jedoch einmal als Fläche und einmal als Ort ("point").

Bei einer Suche nach "historic"="memorial" werden beide Objekte als solche ausgewiesen und können in eine KML-Datei exportiert werden.

Die Objekte in dieser KML-Datei werden in Google Earth jedoch unterschiedlich sichtbar dargestellt. Einmal mit einer Markierung als Punktobjekt ("Stecknadel") und einmal als Fläche (bei einer Büste entsprechend so klein, dass diese Fläche nur im höchsten Maßstab zu sehen ist => unbrauchbar für eine Übersichtsdarstellung).

Gibt es irgendeine Möglichkeit, diese als Flächen ausgewiesenen Objekte zu Punkten zu konvertieren, damit sie auch bei kleinen Maßstäben als Objekte sichtbar sind?

Danke für eine weiterführende Antwort schon vorab.

Hallo -Rubashov-,

Fundmenge in einem OSM-Format bzw. Download der Rohdaten (pbf) von https://www.geofabrik.de/data/download.html

Osmconvert --all-to-nodes

https://wiki.openstreetmap.org/wiki/DE:Osmconvert
https://wiki.openstreetmap.org/wiki/DE:Osmfilter

Eine Verteilung der verschidenen Tags kannst Du schnell mit https://taginfo.openstreetmap.org/ prüfen.

Viel Erfolg
Joachim

Auch in overpass kannst Du Flächen auf Punkte reduzieren:
out center;
siehe https://wiki.openstreetmap.org/wiki/Ove … ne_queries

-Rubashov- wrote:

Gibt es irgendeine Möglichkeit, diese als Flächen ausgewiesenen Objekte zu Punkten zu konvertieren, damit sie auch bei kleinen Maßstäben als Objekte sichtbar sind?

Also in Overpass kannst du entsprechend halt jeweils z.B. den ersten Node vom Way ausgeben lassen, Beispiel (kommentiert):
https://overpass-turbo.eu/s/10OL
Allerdings bekommst du dann halt wirklich nur den Node vom Way in das Ergebnis und an diesem Node hängen keinerlei Informationen in der Regel mehr (also der hat ja nicht die entsprechenden Tags, sondern der Way zu dem er gehört).

Ein anderer Weg ist es, sich halt jeweils die Mittelpunkte bei Relationen/Ways ausgeben zu lassen. Nach dem "out" einfach ein "center" angefügt. Somit wird nur noch der Mittelpunkt eines Ways ausgegeben:
https://overpass-turbo.eu/s/10OM
Edit: Und dieser Mittelpunkt hat dann noch alle Tags des zugehörigen Ways. ;-)

Wenn du die Daten halt schon mit Overpass abgefragt hast, ist sicherlich der Weg von DD1GJ hilfreicher.

Gruß,
asca

DD1GJ wrote:

Hallo -Rubashov-,

Fundmenge in einem OSM-Format bzw. Download der Rohdaten (pbf) von https://www.geofabrik.de/data/download.html

Osmconvert --all-to-nodes

https://wiki.openstreetmap.org/wiki/DE:Osmconvert
https://wiki.openstreetmap.org/wiki/DE:Osmfilter

Eine Verteilung der verschidenen Tags kannst Du schnell mit https://taginfo.openstreetmap.org/ prüfen.

Viel Erfolg
Joachim

Diese nachträgliche Konvertierungsmethode ist zum einen hier deutlich zeitaufwendiger als eine Neuabfrage der Daten mit einem zusätzlichen Parameter und zum anderen bringt die Konvertierung in Google Earth nur Wegpunkte, keine Markierungen. Die Wegpunkte sind zwar schon deutlich besser als nur Flächen, aber bei weitem nicht so sichtbar wie eine Markierung.

Nachfolgende Abfragesynthax führt zum gewünschten Ergebnis, bei dem auch als Denkmal attribuierte Flächen in Google Earth als Markierungen dargestellt werden (sie erscheinen zwei Mal, einmal als Fläche und zusätzlich als Markierung):

// Abfrage OSM

{{geocodeArea:Germany}}->.a;

(
nwr(area.a)[historic=monument];

);

(._; >;);

out meta;

out center;

the-asca wrote:

-Rubashov- wrote:

Gibt es irgendeine Möglichkeit, diese als Flächen ausgewiesenen Objekte zu Punkten zu konvertieren, damit sie auch bei kleinen Maßstäben als Objekte sichtbar sind?

Also in Overpass kannst du entsprechend halt jeweils z.B. den ersten Node vom Way ausgeben lassen, Beispiel (kommentiert):
Ein anderer Weg ist es, sich halt jeweils die Mittelpunkte bei Relationen/Ways ausgeben zu lassen. Nach dem "out" einfach ein "center" angefügt. Somit wird nur noch der Mittelpunkt eines Ways ausgegeben:
https://overpass-turbo.eu/s/10OM

Das war der entscheidende Tip, der bei einer Abfrage mit anschließendem Export in eine KML-Datei in Google Earth die abgefragten Objekte als Markierung darstellt, ungeachtet dessen, ob das Objekt als Punkt oder als Fläche in der OSM-Datenbank eingetragen ist.

Jetzt muss ich nur noch herausfinden, wie ich die einfachen Abfragen wie diese:

//␣Abfrage␣OSM

{{geocodeArea:Germany}}->.a;

(
nwr(area.a)[historic=monument];

);

(._;␣>;);

out␣meta;

out␣center;

so anpasse/ergänze/erweitere, dass ich additive Verknüpfungen und Ausschlüsse bestimmen kann.

Also:

alle "monument" UND "memorial" in Deutschland mit "name"="x"

bzw.

alle Objekte in Deutschland mit "name"="x" aber OHNE "way" UND OHNE "place"

So richtig habe ich diese Abfragesprache noch nicht verstanden. 🤔

"Nebenan" gerade vieles schon erklärt - siehe und die dortigen verlinkten Overpass-Beispiele: https://forum.openstreetmap.org/viewtop … 64#p810564

Ansonsten explizit für deine beiden Overpass-"Anfragen" Beispiele:
https://overpass-turbo.eu/s/10Qa

Bitte zieh den Textbereich so breit, dass es keine Umbrüche gibt, die Kommentare sind extra so formatiert, dass die Linien darauf zeigen, was erklärt wird.

the-asca wrote:

"Nebenan" gerade vieles schon erklärt - siehe und die dortigen verlinkten Overpass-Beispiele: https://forum.openstreetmap.org/viewtop … 64#p810564

Ansonsten explizit für deine beiden Overpass-"Anfragen" Beispiele:
https://overpass-turbo.eu/s/10Qa

Bitte zieh den Textbereich so breit, dass es keine Umbrüche gibt, die Kommentare sind extra so formatiert, dass die Linien darauf zeigen, was erklärt wird.

Danke für die Kommentierung in der Abfrage.

Langsam aber sicher werde ich jedoch verrückt, denn ich finde meinen Fehler nicht.

//␣Abfrage␣nach␣TAG␣"sowjet"␣bei␣"Monument|Memorial"␣in␣BERLIN␣und␣BRANDENBURG
(␣{{geocodeArea:Brandenburg}};␣␣␣.searchArea;)␣->␣.searchArea;
(␣{{geocodeArea:Berlin}};␣␣␣␣␣␣␣␣.searchArea;)␣->␣.searchArea;

(␣nwr␣(area.searchArea)␣[historic=memorial]␣[name~sowjet]␣;␣.result;)␣->␣.result;

(␣nwr␣(area.searchArea)␣[historic=monument]␣[name~sowjet]␣;␣.result;)␣->␣.result;

(␣nwr␣(area.searchArea)␣[monument]␣[name~sowjet]␣;␣.result;)␣->␣.result;

(␣nwr␣(area.searchArea)␣[memorial]␣[name~sowjet]␣;␣.result;)␣->␣.result;

.result␣out␣meta;
.result␣out␣center;

Die Abfrage soll alle diejenigen Objekte ausgeben, die in Berlin und Brandenburg mit "*sowjet*" im Namen als Denkmal (monument|memorial|historic) gekennzeichnet sind.

Ausgegeben werden mit dieser Abfrage 5 Objekte. Das ist ein Bruchteil der Objekte, die ausgegeben werden müssten.

So wird dieses Objekt nicht gefunden, obwohl eindeutig als "historic=memorial" sowie "name"~"sowjet" markiert:

https://www.openstreetmap.org/node/2799 … 8/13.49561

Gleiches gilt für diese Objekte, die ebenso nicht gefunden werden:

https://www.openstreetmap.org/node/2274670443

https://www.openstreetmap.org/node/1557373803

https://www.openstreetmap.org/node/411550902

Was mache ich bei der Abfrage falsch?

"name"~"sowjet" sucht nur nach dem Suchbegriff mit kleinem 's' am Anfang, obwohl die meisten Objekte den Namen mit großem 'S' beginnen. Vielleicht hilft das weiter. Oder nur nach "owjet" suchen.

-Rubashov- wrote:

Was mache ich bei der Abfrage falsch?

"Sowjet" ist halt nicht "sowjet". Gibt 3 Möglichkeiten:
1. Sowohl nach "Sowjet" eine Abfrage, als auch nach "sowjet" (ziemlich dumm, weil alles doppelt durchsucht werden muss, Performance-Fresser)
2. beim Regulärem Ausdruck (kurz RegEx) halt sagen, dass man sowohl großes, als auch kleines S sucht:

[name~"[Ss]owjet"]

(was in eckigen Klammern im RegEx, ist halt ein "irgendeines dieser Zeichen" )
3. einfach sagen, dass bei der Suche mit RegEx generell Groß-/Kleinschreibung missachtet werden soll:

[name~sowjet,␣i]

(Würde dann natürlich auch ein "SowJet" finden ;-)

Denke damit ist dein Problem gelöst. Hier dann noch eine Lösung für ein weiteres "Problem":
Deine Anfrage, ist so geschrieben zwar völlig ok, aber frisst halt viel Performance. Denn du suchst im relativ großem Suchgebiet halt 4x nach Werten. Sprich jedes Objekt im Suchgebiet wird 4x angeschaut und da gibt es natürlich einige.
Gibt jetzt 2 Dinge die du optimieren kannst:
1. weniger oft jedes Objekt erneut "anschauen", dafür aber gleich mehrere Werte prüfen.
Musst dir vorstellen jedes Objekt anschauen ist ein aufwändiges "aus der Schublade holen -> schauen -> zurückpacken". Dann lieber nur 1x rausholen, aber gleich mehrere Dinge überprüfen, geht insgesamt schneller.
Dazu kannst halt jeweils die ersten beiden und die letzten beiden Anfragen zusammenfassen und hast somit nur noch 2 Suchläufe über alle Objekte:

//␣via␣RegEx␣auf␣den␣Key,␣können␣beide␣Keywerte␣gleichzeitig␣gecheckt␣werden.
//␣(RegEx␣auf␣Key␣erfordert␣auch␣RegEx-Suche␣nach␣Value.␣Wenn␣der␣egal,␣dann␣einfach:
//␣".*"␣was␣für␣"irgendwelche␣Zeichen␣irgendwie␣oft"␣steht
(nwr␣(area.searchArea)␣[~"^(monument|memorial)$"~".*"]␣[name~"sowjet",␣i];␣.result;␣)␣->␣.result;

//␣RegEx-Suche␣auf␣historic-Wert,␣somit␣können␣auch␣beide␣Werte␣gleichzeitig␣je␣Objekt␣geprüft␣werden
(nwr␣(area.searchArea)␣[historic~"^(monument|memorial)$"]␣[name~"sowjet",␣i];␣.result;␣)␣->␣.result;

2. Alles hat bei dir den gemeinsame Eigenschaft "name~sowjet". Da du ein grooßes Gebiet hat mit vieelen Objekten, lohnt es sich, erstmal diese extreme Anzahl an Objekten stark zu reduzieren, und dann innerhalb dieser Objekte halt genauer zu filtern.
Sprich in dem Falle: Erstmal ALLE Objekte abfragen, welche "name~sowjet" haben und dann innerhalb derer nach dem monument, memorial, ... schauen. Selbst wenn man für letzteres halt mehrfach die Schubladen öffnen muss, durch das ausfiltern von allem was "nicht-sowjet" ist, überspringt man halt massenhaft Objekte.
Somit voll optimiert (aus meiner aktuellen Sicht), wäre:

[timeout:500];

(␣{{geocodeArea:Brandenburg}};␣␣␣.searchArea;)␣->␣.searchArea;
(␣{{geocodeArea:Berlin}};␣␣␣␣␣␣␣␣.searchArea;)␣->␣.searchArea;

//␣alle␣Sowjet-Sache␣raussuchen:
nwr␣(area.searchArea)␣[name~"sowjet",␣i]␣->␣.sowjetStuff;

//␣nur␣noch␣innerhalb␣der␣Sowjet-Sachen␣suchen:
(nwr.sowjetStuff␣[~"^(monument|memorial)$"~".*"];␣.result;␣)␣->␣.result;
(nwr.sowjetStuff␣[historic~"^(monument|memorial)$"];␣.result;␣)␣->␣.result;

.result␣out␣meta;
.result␣out␣center;

Der Unterschied ist groß. Also mal getestet nur für Berliner Gebiet: 310s Abfragedauer ohne Optimierung, 116s mit den Optimierungen.

2,5. Achja und wenig überraschend geht halt [name~"[Ss]owjet"] schneller als ein [name~"sowjet", i], denn beim ersten muss ja nur 1 Buchstabe mit verschiedenen Variationen berücksichtigt werden. Bedenkt man, dass halt die Sowjet-Sachen raussuchen ja der erste Filter ist, kann man damit noch mehr rausholen:

[timeout:500];

(␣{{geocodeArea:Brandenburg}};␣␣␣.searchArea;)␣->␣.searchArea;
(␣{{geocodeArea:Berlin}};␣␣␣␣␣␣␣␣.searchArea;)␣->␣.searchArea;

//␣alle␣Sowjet-Sache␣raussuchen:
nwr␣(area.searchArea)␣[name~"[Ss]owjet"]␣->␣.sowjetStuff;

//␣nur␣noch␣innerhalb␣der␣Sowjet-Sachen␣suchen:
(nwr.sowjetStuff␣[~"^(monument|memorial)$"~".*"];␣.result;␣)␣->␣.result;
(nwr.sowjetStuff␣[historic~"^(monument|memorial)$"];␣.result;␣)␣->␣.result;

.result␣out␣meta;
.result␣out␣center;

Und man kommt auf etwa 32s. Wenn man 32s den 310s gegenüberstellt, sieht man weshalb es sich lohnt darüber nachzudenken, was da genau passiert ;-)
Auch zum Rumtesten machen 0,5min oder 5min warten ja deutlich ein Unterschied im Spaßfaktor ^^

Gruß,
asca

PS: Ich habe keine Ahnung, in wiefern die Overpass-API(-Server) irgendwelche Werte cachen und ggf. damit auch Werte verzerrt sind, ebenfalls durch unterschiedliche Lastsituationen der Server. Allerdings habe ich die Anfragen mehrfach ausgeführt, auch direkt nach den schnellen Anfragen die performancelastigen. Konnte keine großen Variationen durch mögliches Caching feststellen, ausschließen kann ich es nicht. Das sind also alles nur Angaben hier aus Tests und Logik, kann aber ggf. nicht "perfekt" sein.

FvGordon wrote:

"name"~"sowjet" sucht nur nach dem Suchbegriff mit kleinem 's' am Anfang, obwohl die meisten Objekte den Namen mit großem 'S' beginnen. Vielleicht hilft das weiter. Oder nur nach "owjet" suchen.

Danke für den Hinweis auf die unterschiedliche Handhabung der Groß- und Kleinschreibung bei den Abfragen. Da wäre ich nicht im Traum drauf gekommen. Wieder etwas dazu gelernt. Hat geholfen. Nochmals danke.

the-asca wrote:

PS: Ich habe keine Ahnung, in wiefern die Overpass-API(-Server) irgendwelche Werte cachen und ggf. damit auch Werte verzerrt sind, ebenfalls durch unterschiedliche Lastsituationen der Server. Allerdings habe ich die Anfragen mehrfach ausgeführt, auch direkt nach den schnellen Anfragen die performancelastigen. Konnte keine großen Variationen durch mögliches Caching feststellen, ausschließen kann ich es nicht. Das sind also alles nur Angaben hier aus Tests und Logik, kann aber ggf. nicht "perfekt" sein.

Danke für die Hilfestellung und die Erklärungen.

Eine ergänzende Frage habe ich:

Besteht irgendwie eine Möglichkeit, die OSM-Datenbank für folgendes Szenario zu nutzen:

1. Route von A nach B festlegen.
2. Korridorbreite entlang dieser Route festlegen
3. Anzeigen von Objekten X und Y in diesem Korridor

Anwendungsbeispiel:

Warschau => Berlin (grob entlang der heutigen E30)
50km Korridorbreite
alle Kriegsdenkmäler anzeigen

Gibt es in irgendeiner Form eine Möglichkeit, eine solche Abfrage der OSM-Datenbank auch über ein Web-UI zu realisieren?

Könnte ja dann auch weniger auf historische Datenpunkte ausgerichtet sein, sondern auf rein praktische:

Berlin => Rostock, mit dem Fahrrad, alle Tankstellen | Wasserwanderplätze | Schutzhütten | Campingplätze | etc. im Abstand von 5km zur vorgeschlagenen Route anzeigen

Gibt es eine Möglichkeit diesem Pfad A => B mehre zusätzliche Punkte hinzuzufügen?

Also statt:

Wolgograd => Berlin (alle Kriegsdenkmäler entlang einer 50km Schneise)

Wolgograd => Kursk => Kiew => Warschau => Danzig => Berlin (alle Kriegsdenkmäler entlang einer 50km Schneise)

Danke!

Hmmm... ein Tool dafür kenne ich nicht (wäre aber echt praktisch, gerade für sowas wie von die angesprochene Fahrrad-/Wandertouren).

Einzige "Lösung" die mir einfallen würde wäre eine Route mit online/offline-Tools erstellen und als GPX-Datei abspeichern. Sieht ja dann inhaltlich so aus:

<?xml␣version="1.0"␣encoding="utf-8"?>
<gpx␣xmlns="http://www.topografix.com/GPX/1/1"␣xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"␣xsi:schemaLocation="http://www.topografix.com/GPX/1/1␣http://www.topografix.com/GPX/1/1/gpx.xsd"␣version="1.1">
<metadata>
...
<trk>
<trkseg>
<trkpt␣lat="52.23333"␣lon="21.06873"/>
<trkpt␣lat="52.23353"␣lon="21.06861"/>
<trkpt␣lat="52.23384"␣lon="21.06843"/>
<trkpt␣lat="52.23397"␣lon="21.06835"/>
<trkpt␣lat="52.23397"␣lon="21.06835"/>
...

Mit z.B. Notepad++ die Koordinaten umwandeln zu passender Overpass-Abfrage:

(
nwr(around:10000,52.23333,␣21.06873)␣["monument"];
nwr(around:10000,52.23353,␣21.06861)␣["monument"];
nwr(around:10000,52.23384,␣21.06843)␣["monument"];
nwr(around:10000,52.23397,␣21.06835)␣["monument"];
nwr(around:10000,52.23397,␣21.06835)␣["monument"];
nwr(around:10000,52.23391,␣21.06807)␣["monument"];
nwr(around:10000,52.2339,␣21.06803)␣["monument"];
...
)␣->␣.result;

.result␣out␣center;

Und dann den armen Overpass-API-Server quälen. Warschau -> Berlin sind etwa 5000 Koordinaten. Also 5000x "around"-Suche... na gute Nacht.

the-asca wrote:

Hmmm... ein Tool dafür kenne ich nicht (wäre aber echt praktisch, gerade für sowas wie von die angesprochene Fahrrad-/Wandertouren).

[...]

Und dann den armen Overpass-API-Server quälen. Warschau -> Berlin sind etwa 5000 Koordinaten. Also 5000x "around"-Suche... na gute Nacht.

Wie machen es denn die kommerziellen Anbieter wie Garmin und Co, wenn die die Strecke haben (auch mit Zwischenstationen) und dann die Zusatzaufgabe bekommen Objekt X entlang der Strecke anzuzeigen?

Also mein irgendwas Auto-Garmin zeigt dann wirklich mit einem Abstand von ein paar Kilometer entlang einer Strecke von 500km zum Beispiel alle Tankstellen oder Raststätten oder Bahnhöfe an. Das muss doch auch irgendwie offline gehen und auf einer Maschine, die deutlich schneller ist als jedes mobile Navigationsgerät.

the-asca wrote:

Und dann den armen Overpass-API-Server quälen. Warschau -> Berlin sind etwa 5000 Koordinaten. Also 5000x "around"-Suche... na gute Nacht.

Dem "around"-Filter kann man auch eine Koordinatenliste mitgeben, die man idealerweise vorher vereinfacht:

Since version 0.7.55, it is possible to query for all elements which are within a certain radius of a given linestring, which is given by a list of lat/lon pairs:

(around[.input_set]:radius)
(around:radius,latitude_1,longitude_1,latitude_2,longitude_2,...,latitude_n,longitude_n)

(Und es gibt auch einen "poly" Filter.)

Generell siehe auch Overpass: POIs in der Nähe von Tracks.