You are not logged in.

Announcement

*** NOTICE: forum.openstreetmap.org is being retired. Please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators.
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.***

#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

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 smile


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,928

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

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)

Offline

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

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 10,104

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

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

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

Board footer

Powered by FluxBB