You are not logged in.
- Topics: Active | Unanswered
Announcement
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***
Pages: 1
#1 2016-04-22 21:14:55
- setti
- Member
- Registered: 2013-03-10
- Posts: 7
Overpass Query
Moin,
Hat jemand eine Idee warum ich bei dieser einfachen Overpass Query:
way ["building"="yes"] ({{bbox}});
(._;>;);
out;
auf overpass-turbo.eu als Ergebnis "runtime error: Query run out of memory using about 2048 MB of RAM." bekomme?
Zoomlevel bei der Query war 19.
wohingegen ich bei der Abfrage:
way ["building"="university"] ({{bbox}});
(._;>;);
out;
Ein Ergebnis bekomme wenn entsprechende Daten vorhanden sind.
Danke im Voraus.
setti
Offline
#2 2016-04-23 12:55:13
- Harald Hartmann
- Member
- From: 98667 Schönbrunn
- Registered: 2014-04-02
- Posts: 3,123
- Website
Re: Overpass Query
Kann ich bestätigen, d.h. ich würde das wohl als Bug einstufen und mal melden.
Und es betrifft wohl wirklich nur "building"="yes", da auch einfach nur die Abfrage auf building
[out:json][timeout:25];
(
way["building"]({{bbox}});
);
out body;
>;
out skel qt;
funktioniert...
Mein aktives Gebiet: Gemeinde Schleusegrund
Fingerprint meines Schlüssels: 71F7 3CD9 B647 9079 6B88 326E 8B8B 72AE 34F9 5AAD
Offline
#3 2016-04-23 13:37:11
- mmd
- Member
- Registered: 2010-11-06
- Posts: 2,150
Re: Overpass Query
Hallo,
Roland hat vor ein paar Tagen eine zusätzliche Prüfung eingebaut, um den maximalen Speicher, den eine Query ziehen darf, zunächst auf 2 GB zu begrenzen. Ziel des ganzen ist, einige wildgewordene Queries frühzeitig abbrechen zu können bevor sie Schaden auf dem Server anrichten. Etwas mehr Hintergrund ist hier [1] zu lesen.
Empfehlenswert ist es, alle Probleme der Art "Query run out of memory using about 2048 MB of RAM" zu melden. Es ist nicht ganz unwahrscheinlich, dass der eine oder andere Bug dahinter steckt.
Zurück zum Problem: Bei der genannten Query ist es dummerweise so, dass zunächst alle Objekte weltweit mit building=yes ermittelt werden, bevor dann die BBOX die Ergebnismenge weiter einschränkt. Offensichtlich kostet das ziemlich viel Speicher. Um das ganze von der Reihenfolge her umzudrehen, bietet sich z.B. ein regulärer Ausdruck an:
way ["building"~"^yes$"] ({{bbox}});
(._;>;);
out;
Übrigens kann über den Parameter [maxsize:xxx] auch mehr Speicher angefordert werden... siehe Wiki [3]
btw: Das Problem in diesem Thread habe ich auch unter [2] gepostet.
[1] http://permalink.gmane.org/gmane.comp.g … erpass/237
[2] http://permalink.gmane.org/gmane.comp.g … erpass/247
[3] http://wiki.openstreetmap.org/wiki/Over … maxsize.29
Offline
#4 2016-04-23 13:49:40
- Harald Hartmann
- Member
- From: 98667 Schönbrunn
- Registered: 2014-04-02
- Posts: 3,123
- Website
Re: Overpass Query
...Bei der genannten Query ist es dummerweise so, dass zunächst alle Objekte weltweit mit building=yes ermittelt werden, bevor dann die BBOX die Ergebnismenge weiter einschränkt....
ok, das erklärt natürlich einiges, unschön, aber wenn man es weiss, hilft es ja dennoch weiter
Mein aktives Gebiet: Gemeinde Schleusegrund
Fingerprint meines Schlüssels: 71F7 3CD9 B647 9079 6B88 326E 8B8B 72AE 34F9 5AAD
Offline
#5 2016-04-23 13:50:16
- MKnight
- Member
- Registered: 2012-08-01
- Posts: 2,406
Re: Overpass Query
ich hab mal nen Bug geschrieben: https://github.com/tyrasd/overpass-turbo/issues/234
edit Hups, tabbed browsing ftw ...
Last edited by MKnight (2016-04-23 13:50:48)
gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften
Offline
#6 2016-04-23 14:28:10
- fx99
- Member
- From: Baden-Württemberg
- Registered: 2009-06-02
- Posts: 1,930
Re: Overpass Query
Unschön ist dabei aus meiner Sicht, dass die Reihenfolge der Abfragen nicht wirklich vorhersehbar ist:
way["building"]({{bbox}}); müsste bei gleicher Abarbeitungsreihenfolge noch mehr Objekte ergeben als
way ["building"="yes"] ({{bbox}});
Warum sich hier die Reihenfolge umkehrt, ist mir genauso wie bei
way ["building"~"^yes$"] ({{bbox}}); unklar.
Offline
#7 2016-04-23 17:55:48
- setti
- Member
- Registered: 2013-03-10
- Posts: 7
Re: Overpass Query
Ich war mir nicht bewusst das zuerst alle buildings zusammen gesammelt werden und dann darauf die bbox ausgeschnitten wird. Das macht natürlich nicht viel Sinn. Ich werde es mit den reguläreren Ausdrücken probieren.
Ich würde mich auch noch den Fragen von fx99 anschließen und würde gerne Wissen warum sich die Reihenfolge bei regulären Ausdrücken umdreht.
Vielen Dank an alle.
Offline
#8 2016-04-23 18:48:46
- slhh
- Member
- Registered: 2012-09-02
- Posts: 358
Re: Overpass Query
Ein Prüfen auf reguläre Ausdrücke ist ja recht kompliziert, daher macht man es wohl nur nach Einschränkung auf die Bounding-Box.
Eine Auswahl eines bestimmten Tags sollte für eine geeignet aufgesetzte Datenbank aber sehr einfach sein. Daher kommt das wohl zuerst, auch wenn dies bei häufigen Tags eine Fehlentscheidung sein mag.
Wenn man nur den Key abfragt, könnte dies eventuell nicht so gut zur Datenbankstruktur passen oder man ist hierbei von einer großen Datenmenge ausgegangen, so dass eine Bearbeitung nach der Bounding-Box auch logisch erscheint.
Vermutlich wäre es besser, zunächst mit einer Taginfo-artigen Tabelle die Häufigkeit des Tags/Keys zu bestimmen und danach die Reihenfolge festzulegen.
Offline
#9 2016-04-23 19:00:37
- mmd
- Member
- Registered: 2010-11-06
- Posts: 2,150
Re: Overpass Query
Hallo,
die Frage wäre natürlich am besten bei Roland aufgehoben... ich gebe hier mal meine stark vereinfachte Sichtweise wieder.
Erstmal gibt es keine Statistiken oder Histogramme, mit deren Hilfe ein Optimizer einen möglichst brauchbaren Ausführungsplan ermitteln kann. Stattdessen kommen eher Heuristiken zum Tragen, die grundsätzlich darüber entscheiden, ob Tags eher am Anfang oder erst am Schluß zum Filtern verwendet werden sollen. Dabei wird z.B. geschaut, ob die angegebene BBox eine gewisse Größe nicht überschreitet.
way[key] ist tendenziell eher wenig selektiv. Für den gesamten Planet ist also eher mit einer ziemlich großen Menge an Ergebnissen zu rechnen. Für kleine Gebiete spricht alles dafür, [key] erst am Ende zu betrachten, wenn z.B. die BBox die Ergebnisliste bereits stark reduziert hat.
way[key~"regex_value"] und way[~"regex key"~"regex value"] sind beide relativ teuer (CPU-Kosten für den regulären Ausdruck) und sollten möglichst nicht erst weltweit auf allen Tags durchgerechnet werden, wenn das Suchgebiet eh recht klein ist.
Anders die Situation bei way[key=value]: dort wird aktuell angenommen, dass damit die Ergebnismenge schnell signifikant reduziert werden kann, sprich [key=value] sehr selektiv wirkt. Bei [building=yes] ist das wie oben schon beschrieben nicht der Fall. Dennoch werden zunächst weltweit die relevanten Ways ermittelt und dann erst nach BBOX gefiltert.
Mit der Umstellung auf den regulären Ausdruck habe ich also einfach eine andere Auswertereihenfolge erzwungen. Allerdings rechne ich damit, dass in nächster Zeit möglicherweise auch [key=value] nochmal von Roland angepackt wird und sich die Situation dort verbessert... we'll see.
Wer es ganz genau wissen will, dem empfehle ich einen Blick in die Sourcen.
Last edited by mmd (2016-04-23 19:07:42)
Offline
#10 2016-04-24 20:04:27
- setti
- Member
- Registered: 2013-03-10
- Posts: 7
Re: Overpass Query
Vielen Dank für die Erläuterung.
setti
Offline
#11 2016-04-24 21:52:25
- MKnight
- Member
- Registered: 2012-08-01
- Posts: 2,406
Re: Overpass Query
Ok, ist dann das Problem auch für mich nachvollziehbar.
gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften
Offline
#12 2016-04-25 08:36:43
- mmd
- Member
- Registered: 2010-11-06
- Posts: 2,150
Re: Overpass Query
Allerdings rechne ich damit, dass in nächster Zeit möglicherweise auch [key=value] nochmal von Roland angepackt wird und sich die Situation dort verbessert... we'll see.
Frei nach dem Motto: was interessiert mich mein Geschwätz von gestern: das mit dem regulären Ausdruck als Workaround ist nicht mehr notwendig. Roland war gestern fleißig und hat das Problem inzwischen gefixt! Besten Dank dafür.
Wenn [key=value] nun zu viele Treffer ermittelt - ich glaube es müssten etwas mehr als 1 Mio. sein - wird automatisch eine vorteilhaftere Auswertungsstrategie gezogen.
Last edited by mmd (2016-04-25 08:38:18)
Offline
#13 2017-04-20 19:34:57
- chris66
- Member
- From: Germany
- Registered: 2009-05-24
- Posts: 10,128
Re: Overpass Query
Hi,
Frage zum Overpass Turbo:
kann man irgendwie den Schwellwert für die Warnbox "Die Abfrage liefert viele Daten" beeinflussen?
Chris
Mapper aus dem Münsterland.
Offline
#14 2017-04-20 19:47:13
- mmd
- Member
- Registered: 2010-11-06
- Posts: 2,150
Re: Overpass Query
kann man irgendwie den Schwellwert für die Warnbox "Die Abfrage liefert viele Daten" beeinflussen?
Noch nicht. Siehe https://github.com/tyrasd/overpass-turbo/issues/248
Offline
#15 2017-04-21 15:38:19
- kazadam
- Member
- Registered: 2013-10-16
- Posts: 72
- Website
Re: Overpass Query
Hey, if it is not a topic of this conversation - great sorry!
But,
I need geo date for "schneelastzonen" in Germany due to Eurocode (.poly, .osm, GEOJosn etc ...). Could someone halp me to get it (the most perfect result)?
Thank You,
Offline
#16 2017-04-21 15:45:34
- Harald Hartmann
- Member
- From: 98667 Schönbrunn
- Registered: 2014-04-02
- Posts: 3,123
- Website
Re: Overpass Query
Yes, isn't a topic of this conversation, because i don't know, that any "schneelast"-boundaries are tagged in OSM?!
Mein aktives Gebiet: Gemeinde Schleusegrund
Fingerprint meines Schlüssels: 71F7 3CD9 B647 9079 6B88 326E 8B8B 72AE 34F9 5AAD
Offline
Pages: 1