Overpass Query

setti · 2016-04-22 21:14:55

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

Harald Hartmann · 2016-04-23 12:55:13

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

mmd · 2016-04-23 13:37:11

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

Harald Hartmann · 2016-04-23 13:49:40

mmd wrote:

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

MKnight · 2016-04-23 13:50:16

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)

fx99 · 2016-04-23 14:28:10

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.

setti · 2016-04-23 17:55:48

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.

slhh · 2016-04-23 18:48:46

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.

mmd · 2016-04-23 19:00:37

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)

setti · 2016-04-24 20:04:27

Vielen Dank für die Erläuterung.
setti

MKnight · 2016-04-24 21:52:25

Ok, ist dann das Problem auch für mich nachvollziehbar.

mmd · 2016-04-25 08:36:43

mmd wrote:

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)

chris66 · 2017-04-20 19:34:57

Hi,
Frage zum Overpass Turbo:

kann man irgendwie den Schwellwert für die Warnbox "Die Abfrage liefert viele Daten" beeinflussen?

Chris

mmd · 2017-04-20 19:47:13

chris66 wrote:

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

kazadam · 2017-04-21 15:38:19

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,

Harald Hartmann · 2017-04-21 15:45:34

Yes, isn't a topic of this conversation, because i don't know, that any "schneelast"-boundaries are tagged in OSM?!

Announcement

#1 2016-04-22 21:14:55

Overpass Query

#2 2016-04-23 12:55:13

Re: Overpass Query

#3 2016-04-23 13:37:11

Re: Overpass Query

#4 2016-04-23 13:49:40

Re: Overpass Query

#5 2016-04-23 13:50:16

Re: Overpass Query

#6 2016-04-23 14:28:10

Re: Overpass Query

#7 2016-04-23 17:55:48

Re: Overpass Query

#8 2016-04-23 18:48:46

Re: Overpass Query

#9 2016-04-23 19:00:37

Re: Overpass Query

#10 2016-04-24 20:04:27

Re: Overpass Query

#11 2016-04-24 21:52:25

Re: Overpass Query

#12 2016-04-25 08:36:43

Re: Overpass Query

#13 2017-04-20 19:34:57

Re: Overpass Query

#14 2017-04-20 19:47:13

Re: Overpass Query

#15 2017-04-21 15:38:19

Re: Overpass Query

#16 2017-04-21 15:45:34

Re: Overpass Query

Board footer