> >> Die Funktion zur Berechnung der Entfernung steht in der GeoClass
> >> oder auch auf den opengeodb Seiten (FAQ?). Einer sagt asin(), der
> nächste arcsin() usw. usf.: es sind ja nur syntaktische Unterschiede.
Jo und das sagt mir alles mal gar nix. Hab noch nie in meinem
Leben asin() oder arcsin() benutzen müssen. Allerdings sehe ich
auch in der Formel nix von asin() oder arcsin()...
> Naja, was soll das schon heißen? Auf jeden Fall kann man sie so
> formulieren, daß postgres sie versteht.
Jo, ich dachte halt, es hat vielleicht schon mal Jemand gemacht und
kann kurz die fertige Formel aus der Tasche ziehen. Wie ich jetzt
durch rtfm herausgefunden habe scheint die Funktion unter Postgres
zu funktionieren wenn man arccos() mit acos() ersetzt. Frage dazu
kommt noch am Ende dieser Mail.
> WGS84 ist das Koordinatensystem, das für Koordinaten weltweit üblich
> geworden ist.
Aha. Okay. Muß ich mich jetzt schämen oder darf man als
normalsterblicher Programmiererfuzzi auch noch nie davon gehört haben?
> Ich meinte, ich weiß sie gerade nicht... Wie dem auch sei: wenn Du die
> Textvariante mit einer entsprechender DB-Relation nimmst, dann brauchst
> Du Dich eh nicht um diese Typen zu kümmern.
Einer der Gründe, warum ich die copy/textvariante bevorzuge. ;-)
> Es gibt einen Ansatz, daß man in der DB nach Längen- und Breitengraden
> vorfiltert (... where latitude < $breite-0.1 and latitude > $breite+0.1
> o.ä.), um anschließend im Programm selber nochmal zu schauen, ob diese
> Daten tatsächlich im gewünschten Bereich liegen. Damit reduziert man
> den Aufwand schon mal beträchtlich.
Macht Sinn.
Allerdings: Wenn ich nun einen relativ großen radius definiere,
dann wird die Menge die ich zurückerhalte beträchtlich sein.
Diese muß ich dann in einem Loop abarbeiten.
Nehmen wir an, ich erhalte 1.000 potentielle Kandidaten zurück und die
Funktion zur Berechnung braucht 5ms pro Satz, dann sind wir auch schon
wieder bei 5 Sekunden - nur für diesen Teil. Vorher lief ja schon die
SQL-Abfrage, die hat ja auch schon etwas zeit benötigt.
Nehmen wir nun an, innerhalb der 5 Sekunden startet ein zweiter User
ebenfalls eine Abfrage. Dadurch werden die 5ms (falls die überhaupt
irgendwie realistisch sind) nicht mehr gehalten werden können (außer evtl.
auf einem SMP-System, je nachdem) und dann dauert es noch länger.
> Das geht auch, man muß nur schauen, ob die Relationen nicht zu
> groß werden.
Dun meinst vermutlich im Sinne von "wenn der Radius nicht zu
groß wird", richtig?
> >Man könnte ja sogar Tabellen erzeugen nach dem Schema
> >"plz0_range30" bis "plz9_range30" also gesplittet nach
> >der ersten Ziffer.
> >
> Oder halt eine Relation mit einer Info über den Bereich.
Hm? darunter kann ich mir jetzt nix vorstellen.
> Die mir bekannten Programme, sprich die GeoClass macht
> halt diese Anfrage mit der komplizierten Funktion in
> der Where Klausel inkl. Verzicht auf Indexe.
Wie lange dauert denn so eine Abfrage auf einem
handelsüblichen PC derzeit mit Verzicht auf Indices und einem
Radius von sagen wir mal 15km?
Hat das mal Jemand gemessen?
Alles über 600ms wäre in meinem Fall dann schon langsam kritisch...
> Und ich
> habe bislang noch keine Performanceprobleme gesehen.
> Was natürlich nicht viel heißt, aber "irgendwas"
> Erkennbares hätte ich schon erwartet.
Hmm, wird denn die opengeodb in irgendwelchen Referenzanwendungen
benutzt wo richtig traffic herrscht?
Kommen wir noch kurz zur FAQ:
-------------------------------
arccos(sin(B_lat)*sin(A_lat)+cos(B_lat)*cos(A_lat)*cos(B_lon - A_lon)) *
Erdradius
Mit dem Erdradius von etwa 6380 km. Die Längengrade und Breitengrade müssen
in das Bogenmaäß konvertiert werden, wenn die sin() und cos() Funktionen es
so erwarten. Das geschieht durch die Multiplikation der Werte aus der
Datenbank mit PI/180.
-------------------------------
1. _lat und _lon sind vermutlich latitude und longitude, richtig?
2. "Bogenmaß, wenn die sin() und cos() Funktionen es so erwarten"
Woher weiß ich denn, ob die das so erwarten? Was ist denn ein
Bogenmaß? Die sin() und cos() Funktionen unter Postgres jedenfalls
"take arguments and return values of type double precision"
Also müsste ich die Werte direkt nehmen können, wie sie in den
textdateien drinstehen, richtig?
3. In der Doku von Postgres finde ich nix über arccos, dafür aber
eine Funktion acos() definiert als "acos(x) - inverse cosine"
Ist das die Richtige?
Sorry für meine dummen Fragen und vielen Dank für Deine Hilfe!!
Gruß,
Oli
--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
|
