On Mon, 27 Apr 2009 16:04:01 +0200, Christof Amelunxen <christof.amelun...@sbg.ac.at> wrote: >> Sie sollte zuerst den Index mit dem kleinsten CostFactor anwenden >> (also entweder den Vergleich auf "key" und "value" in Tag oder >> die Bounding-Box auf location). Eine gute Datenbank wird das >> Ergebniss mit dem zweiten Index weiter verkleinern können, eine >> weniger gute muss da schon anfangen alle Ergebnisse auf die weiteren >> Bedingungen hin zu testen. > > Das Problem ist die aggregate function "MIN" in Kombination mit > Distance(x,y), denn hierfür müssen zunächst einmal alle > Kombinationen ausgerechnet werden, da hilft dir auch kein räumlicher Index > weiter, denn die werden bei dieser Abfrage > nicht benutzt (zumindest nicht bei PostGIS oder Oracle Spatial).
Er macht doch nur ein MIN auf den Einträgen, welche dem WHERE entsprechen. Oder habe ich hier was Grundsätzliches an SQL falsch verstanden? >> Da eine Geodatenbank wohl sinnvoll einen Punkt oder einen Linestring >> nach Enthaltensein in einer Bounding-Box/in einem Kreis testen kann >> sehe ich hier kein Problem. >> (The details are left as an exercise to the reader.) > > Deshalb mein Hinweis auf ST_DWithin statt MIN(Distance(x,y)), denn genau > dafür ist die Funktion da. Mit Distance(x,y) > klappt das nicht und da wollte ich nur drauf hinweisen. Ich nehme an ST_DWithin liefert dir alle elemente welche "within" sind und nicht das eine nächstgelegene welche der bounding-box aus der WHERE Bedingung entspricht? Ich denke mal wir können abschliessen: * Es ist mit SQL möglich den einen oder keinen Ort zu einem Punkt entsprechend der aktuell im Wiki dokumentierten Semantik zu finden. * Es ist mit SQL auf einer Datenbank mit 2D-index effizient möglich. Einverstanden? Marcus _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
