Discussion:
mehrere BETWEEN - Abfrage (Umkreissuche)
(zu alt für eine Antwort)
Jens Steinführer
2006-11-22 12:13:17 UTC
Permalink
hallo,

ich habe ein Problem mit der MYSQL-Abfrage.
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
sich z.B. 10km vom Ursprungsort befinden. Da vorhandene Systeme sehr
umfangreich sind (von den Berechnungen her,etc.), hab ich aus der
Radiussuche eine Quadratsuche gemacht (also 10 links, rechts, oben und
unten).

Der Aufruf nach den Erstellen der Variablen lautet bei mir:

$result1 = mysql_query("SELECT id FROM gort WHERE (laenge BETWEEN
'$lang_o2' AND '$lang_u2') AND (breite BETWEEN '$breite_o2' AND
'$breite_u2) ORDER BY ort ASC;");
...


Aber komischerweise werden nicht alle in Frage kommenden Orte
angezeigt. Kann jemand mir mal sagen, ob die SQL-Anweisung einen
Logikfehler hat bzw. wie dann der Ansatz sein sollte?

MfG
Jens Steinführer
Claus Reibenstein
2006-11-22 13:13:22 UTC
Permalink
Post by Jens Steinführer
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
sich z.B. 10km vom Ursprungsort befinden. Da vorhandene Systeme sehr
umfangreich sind (von den Berechnungen her,etc.), hab ich aus der
Radiussuche eine Quadratsuche gemacht (also 10 links, rechts, oben und
unten).
Ich stand mal vor genau dem gleichen Problem und habe einen anderen
Lösungsansatz versucht: ich habe eine Entfernungstabelle erzeugt. Als
maximale Entfernung habe ich 50 km gewählt und dabei eine Tabelle mit
ca. 1,7 Millionen Einträgen erhalten (ohne Begrenzung wären es ca. 70
Millionen geworden). Die Erzeugung dieser Tabelle hat einmalig ca. 3,5
Stunden in Anspruch genommen. Alle darauf aufbauenden Suchen sind jedoch
rasend schnell, und ich kann auch problemlos nach Entfernung sortieren.
Post by Jens Steinführer
$result1 = mysql_query("SELECT id FROM gort WHERE (laenge BETWEEN
'$lang_o2' AND '$lang_u2') AND (breite BETWEEN '$breite_o2' AND
'$breite_u2) ORDER BY ort ASC;");
Warum setzt Du die Längen bzw. Breiten in Anführungsstriche? Sind sie in
der Datenbank nicht als numerische Werte enthalten? Die
Anführungsstriche sollten zwar eigentlich kein Problem darstellen, aber
man weiß ja nie.
Post by Jens Steinführer
Aber komischerweise werden nicht alle in Frage kommenden Orte
angezeigt. Kann jemand mir mal sagen, ob die SQL-Anweisung einen
Logikfehler hat bzw. wie dann der Ansatz sein sollte?
Die Werte für $lang_o2, $lang_u2, $breite_o2 und $breite_u2 hast Du
geprüft? Die fehlenden Orte stehen auch mit den richtigen Werten in der DB?

Ansonsten wüsste ich nicht, was da falsch sein könnte.

Übrigens: <news:de.comp.lang.php.datenbanken> existiert. Ich leite mal
dahin um.

Gruß. Claus
--
,~°O O
O <http://www.wedding-card.de/> ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /
Matthias P. Wuerfl
2006-11-22 13:23:42 UTC
Permalink
Post by Jens Steinführer
$result1 = mysql_query("SELECT id FROM gort WHERE (laenge BETWEEN
'$lang_o2' AND '$lang_u2') AND (breite BETWEEN '$breite_o2' AND
'$breite_u2) ORDER BY ort ASC;");
Sieht gut aus.

Setze mal zuerst die Query mit allen Variablen zusammen, lasse sie Dir
dann ausgaben und setze sie dann ab.

<?php

$query1 = "
SELECT
id
FROM
gort
WHERE
(laenge BETWEEN '$lang_o2' AND '$lang_u2')
AND
(breite BETWEEN '$breite_o2' AND '$breite_u2)
ORDER BY
ort ASC
;");

echo $query1; #debug

$result1 = mysql_query($query1);

?>

Und sag' mal was das ausgibt. Vermutung: In den Variablen steht etwas
drin, was Du entweder nicht erwartest oder zumindest anders
interpretierst als der Datenbankserver (Komma/Punkt, etc.).

Grüße, Matthias
--
http://www.trullala.de
--
Der Trend geht ganz eindeutig zur Zweitsignatur.
Jens Steinführer
2006-11-24 08:14:01 UTC
Permalink
Post by Matthias P. Wuerfl
Setze mal zuerst die Query mit allen Variablen zusammen, lasse sie Dir
dann ausgaben und setze sie dann ab.
...
Post by Matthias P. Wuerfl
Und sag' mal was das ausgibt. Vermutung: In den Variablen steht etwas
drin, was Du entweder nicht erwartest oder zumindest anders
interpretierst als der Datenbankserver (Komma/Punkt, etc.).
ja Matthias, Du hattest recht, der Fehler lag nicht in der Logik,
sondern in der Variable (es fehlte ne 0 am Ende)

Jetzt funktionierts wies soll: auf www.sachsennetz.de (Suchmaschine -
Ortssuche)


MfG
Jens

P.S.: ich war mir sicher, dass ich schon mal geantwortet hab, nur
scheint irgendwie was mit der neuen Beta-Newsgroup Software von Google
nicht gepasst zu haben... oder ich war zu doof zum abschicken... grins
Jens Riedel
2006-11-22 19:16:18 UTC
Permalink
Post by Jens Steinführer
$result1 = mysql_query("SELECT id FROM gort WHERE (laenge BETWEEN
'$lang_o2' AND '$lang_u2') AND (breite BETWEEN '$breite_o2' AND
'$breite_u2) ORDER BY ort ASC;");
Falls laenge und breite in der DB als Textfelder angelegt sind (du
verwendest ja hier Hochkommata, um die Werte anzugeben), wird natürlich
auch kein numerischer Vergleich gemacht.
'200' wäre dann nicht BETWEEN '10' and '100', obwohl das numerisch
gesehen natürlich der Fall ist.

Jens
--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach
Claus Reibenstein
2006-11-22 21:00:28 UTC
Permalink
Post by Jens Riedel
'200' wäre dann nicht BETWEEN '10' and '100', obwohl das numerisch
gesehen natürlich der Fall ist.
Wie meinen?

Gruß. Claus
--
,~°O O
O <http://www.wedding-card.de/> ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /
Rudi Menter
2006-11-22 21:10:17 UTC
Permalink
Post by Claus Reibenstein
Post by Jens Riedel
'200' wäre dann nicht BETWEEN '10' and '100', obwohl das numerisch
gesehen natürlich der Fall ist.
Wie meinen?
Balla balla!
Post by Claus Reibenstein
Gruß. Claus
--
,~°O O
O <http://www.wedding-card.de/> ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /
Niels Braczek
2006-11-22 21:33:02 UTC
Permalink
Post by Jens Riedel
'200' wäre dann nicht BETWEEN '10' and '100', obwohl das numerisch
gesehen natürlich der Fall ist.
Du meintest sicher '20'...

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Jens Riedel
2006-11-23 08:17:43 UTC
Permalink
Post by Niels Braczek
Du meintest sicher '20'...
Selbstverständlich... man sollte bei Fieber nicht nur nicht ernsthaft
arbeiten, sondern auch seine NG-Beiträge schärfer korrekturlesen ;-)

Jens
--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach
Jens Steinführer
2006-11-24 08:16:52 UTC
Permalink
Post by Jens Riedel
'200' wäre dann nicht BETWEEN '10' and '100', obwohl das numerisch
gesehen natürlich der Fall ist.Du meintest sicher '20'...
in meinem Fall scheint dies nicht relevant zu sein, trotz Hochkomma
wird nun das gewünsche Ergebnis angezeigt.
n.Olivier
2006-11-24 22:49:51 UTC
Permalink
Hi
Post by Jens Steinführer
hallo,
ich habe ein Problem mit der MYSQL-Abfrage.
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
sich z.B. 10km vom Ursprungsort befinden. Da vorhandene Systeme sehr
umfangreich sind (von den Berechnungen her,etc.), hab ich aus der
Radiussuche eine Quadratsuche gemacht (also 10 links, rechts, oben und
unten).
$result1 = mysql_query("SELECT id FROM gort WHERE (laenge BETWEEN
'$lang_o2' AND '$lang_u2') AND (breite BETWEEN '$breite_o2' AND
'$breite_u2) ORDER BY ort ASC;");
Das was du da machst ist noch umfangreicher.

Mit der radialberechnung und richtigen indexen geht das verdammt
schell und bedeutend einfacher.

vorlage z.B.:
http://www.plogmann.net/w/2/59/index.htm

Alles andere ist unbrauchbar wenn du wirkliche ergebnisse willst.

gruß n.Olivier
--
Nachbagauer Olivier - www.nOlivier.com
www.reedb.com - Immobilien national & international
Webportal der Immobilien-Branche - www.Immofinder.de
Helmut Hullen
2006-11-25 08:40:00 UTC
Permalink
Hallo, n.Olivier,
Post by n.Olivier
Post by Jens Steinführer
ich habe ein Problem mit der MYSQL-Abfrage.
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
sich z.B. 10km vom Ursprungsort befinden. Da vorhandene Systeme
sehr umfangreich sind (von den Berechnungen her,etc.), hab ich aus
der Radiussuche eine Quadratsuche gemacht (also 10 links, rechts,
oben und unten).
$result1 = mysql_query("SELECT id FROM gort WHERE (laenge BETWEEN
'$lang_o2' AND '$lang_u2') AND (breite BETWEEN '$breite_o2' AND
'$breite_u2) ORDER BY ort ASC;");
Das was du da machst ist noch umfangreicher.
Mit der radialberechnung und richtigen indexen geht das verdammt
schnell und bedeutend einfacher.
Sicher? Das wäre

r^2 = (dx)^2 + (dy)^2

dx und dy beschaffen: das muss der obige Aufruf auch. Quadrieren
dauert länger.
Aufs Wurzelziehen kann er verzichten - Abfrage auf das Quadrat reicht.

Aber der obige Aufruf dürfte abbrechen, wenn bereits dy zu gross ist:
das dürfte Zeit sparen.

Viele Grüße!
Helmut
n.Olivier
2006-11-25 14:35:03 UTC
Permalink
Hi
Post by Helmut Hullen
Hallo, n.Olivier,
Post by Jens Steinführer
ich habe ein Problem mit der MYSQL-Abfrage.
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
[...]
Post by Helmut Hullen
das dürfte Zeit sparen.
Die Formel selbst ist, nun ja etwas komplexer, aber eine
Abfrage dauert normalerweise < 0.5 sec je nach anzahl,
umkreis, sortierung und datenbestand.

Bin gerade selbst dabei anhand von Geokoordinaten (für
ganz Europa im Endausbau) so eine Lösung auf die Beine
zu stellen.

Mit der Formel habe ich angefangen (aus OpenGeoDB für PHP):

IFNULL((ACOS((SIN(RADIANS(<Ort_breiten_grad>)) *
SIN(RADIANS(location.geo_br)))
+ (COS(RADIANS(<Ort_breiten_grad>))*COS(RADIANS(location.geo_br)) *
COS(RADIANS(location.geo_ln)-RADIANS(<Ort_laengen_grad>))))
* <erdradius>),0)< <umkreis>

gruß Olivier
--
Nachbagauer Olivier - www.nOlivier.com
www.reedb.com - Immobilien national & international
Webportal der Immobilien-Branche - www.Immofinder.de
Helmut Hullen
2006-11-25 15:50:00 UTC
Permalink
Hallo, n.Olivier,
Post by n.Olivier
Post by Helmut Hullen
Post by Jens Steinführer
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
[...]
Post by Helmut Hullen
das dürfte Zeit sparen.
Die Formel selbst ist, nun ja etwas komplexer, aber eine
Abfrage dauert normalerweise < 0.5 sec je nach anzahl,
umkreis, sortierung und datenbestand.
Bin gerade selbst dabei anhand von Geokoordinaten (für
ganz Europa im Endausbau) so eine Lösung auf die Beine
zu stellen.
IFNULL((ACOS((SIN(RADIANS(<Ort_breiten_grad>)) *
SIN(RADIANS(location.geo_br)))
+ (COS(RADIANS(<Ort_breiten_grad>))*COS(RADIANS(location.geo_br))
* COS(RADIANS(location.geo_ln)-RADIANS(<Ort_laengen_grad>))))
* <erdradius>),0)< <umkreis>
Klingt noch schlimmer - da sind aufwändige Rechenoperationen nötig,
ohne dass die übliche Genauigkeit auch tatsächlich gefordert ist. Die
Abfrage nach x+/-dx, y+/-dy (also ob der gesuchte Ort innerhalb eines
Rechtecks oder Quadrats liegt) dürfte erheblich schneller sein.

Viele Grüße!
Helmut
Niels Braczek
2006-11-25 18:15:12 UTC
Permalink
Post by Helmut Hullen
Hallo, n.Olivier,
Post by n.Olivier
IFNULL((ACOS((SIN(RADIANS(<Ort_breiten_grad>)) *
SIN(RADIANS(location.geo_br)))
+ (COS(RADIANS(<Ort_breiten_grad>))*COS(RADIANS(location.geo_br))
* COS(RADIANS(location.geo_ln)-RADIANS(<Ort_laengen_grad>))))
* <erdradius>),0)< <umkreis>
Klingt noch schlimmer - da sind aufwändige Rechenoperationen nötig,
ohne dass die übliche Genauigkeit auch tatsächlich gefordert ist. Die
Abfrage nach x+/-dx, y+/-dy (also ob der gesuchte Ort innerhalb eines
Rechtecks oder Quadrats liegt) dürfte erheblich schneller sein.
Das ist schnell genug. Ich setze eine ähnliche Formel schon länger in
einer professionellen Anwendung ein. Man soll nicht unterschätzen, was
ein DBMS zu leisten imstande ist. Wenn eine solche Berechnung zum
Flaschenhals wird, braucht man eine (C-)Webserver-Erweiterung und kein
PHP-Skript.

MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
n.Olivier
2006-11-26 10:35:45 UTC
Permalink
Hi
Post by Helmut Hullen
Hallo, n.Olivier,
Post by n.Olivier
Post by Helmut Hullen
Post by Jens Steinführer
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
[...]
Post by Helmut Hullen
das dürfte Zeit sparen.
Die Formel selbst ist, nun ja etwas komplexer, aber eine
Abfrage dauert normalerweise < 0.5 sec je nach anzahl,
umkreis, sortierung und datenbestand.
Bin gerade selbst dabei anhand von Geokoordinaten (für
ganz Europa im Endausbau) so eine Lösung auf die Beine
zu stellen.
IFNULL((ACOS((SIN(RADIANS(<Ort_breiten_grad>)) *
SIN(RADIANS(location.geo_br)))
+ (COS(RADIANS(<Ort_breiten_grad>))*COS(RADIANS(location.geo_br))
* COS(RADIANS(location.geo_ln)-RADIANS(<Ort_laengen_grad>))))
* <erdradius>),0)< <umkreis>
Klingt noch schlimmer - da sind aufwändige Rechenoperationen nötig,
ohne dass die übliche Genauigkeit auch tatsächlich gefordert ist. Die
Abfrage nach x+/-dx, y+/-dy (also ob der gesuchte Ort innerhalb eines
Rechtecks oder Quadrats liegt) dürfte erheblich schneller sein.
Die Erde ist nun mal kein Quadrat :-)

Und wenn die die Berechnungen mit Quadrat machst, hast du schnell
mal Abweichungen von 10 oder 20 km was nicht unbedeutend ist, wobei
hingegen eine gewisse unschärfe (in Grenzen) gewünscht sein kann.

Und wie Niels schrieb, sollte die Formel kein für eine DB kein
Problem darstellen.

gruß n.Olivier
--
Nachbagauer Olivier - www.nOlivier.com
www.reedb.com - Immobilien national & international
Webportal der Immobilien-Branche - www.Immofinder.de
Helmut Hullen
2006-11-26 11:11:00 UTC
Permalink
Hallo, n.Olivier,
Post by n.Olivier
Post by Helmut Hullen
Post by n.Olivier
IFNULL((ACOS((SIN(RADIANS(<Ort_breiten_grad>)) *
SIN(RADIANS(location.geo_br)))
+ (COS(RADIANS(<Ort_breiten_grad>))*COS(RADIANS(location.geo_br)
)
* COS(RADIANS(location.geo_ln)-RADIANS(<Ort_laengen_grad>))))
* <erdradius>),0)< <umkreis>
Klingt noch schlimmer - da sind aufwändige Rechenoperationen
nötig, ohne dass die übliche Genauigkeit auch tatsächlich
gefordert ist. Die Abfrage nach x+/-dx, y+/-dy (also ob der
gesuchte Ort innerhalb eines Rechtecks oder Quadrats liegt) dürfte
erheblich schneller sein.
Die Erde ist nun mal kein Quadrat :-)
Ja und?
Welche Genauigkeit ist gefordert? "im Umkreis" ist nur eine von
etlichen möglichen Anforderungen.
Post by n.Olivier
Und wie Niels schrieb, sollte die Formel kein für eine DB kein
Problem darstellen.
Technisch sicherlich unproblematisch. Ich vermute aber, dass die
erforderliche Rechenzeit erheblich grösser ist als bei einer (x+/-dx,
y+/-dy)-Suche, bei einer "BETWEEN"-Suche. Und es könnte sein, dass die
Rechenzeit auch ein Problem werden kann.

Viele Grüße!
Helmut
Niels Braczek
2006-11-26 12:07:25 UTC
Permalink
Post by Helmut Hullen
Hallo, n.Olivier,
Post by n.Olivier
Und wie Niels schrieb, sollte die Formel kein für eine DB kein
Problem darstellen.
Technisch sicherlich unproblematisch. Ich vermute aber, dass die
erforderliche Rechenzeit erheblich grösser ist als bei einer (x+/-dx,
y+/-dy)-Suche, bei einer "BETWEEN"-Suche. Und es könnte sein, dass die
Rechenzeit auch ein Problem werden kann.
Natürlich ist die Rechenzeit höher. Die Abfrage über einige zig-Tausend
Datensätze dauert fast zwei Millisekunden länger als die gleiche Abfrage
mit Pythagoras. Dafür kann ich eine Umkreissuche auch im Bereich von 100
oder gar 1000 km ohne nennenswerte Fehler machen.

Geschwindigkeit ist kein Gott. Man sollte ihr nicht die Qualität opfern.

MfG
NIels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Michael Fesser
2006-11-26 19:52:25 UTC
Permalink
.oO(Helmut Hullen)
Post by Helmut Hullen
Ja und?
Welche Genauigkeit ist gefordert? "im Umkreis" ist nur eine von
etlichen möglichen Anforderungen.
"Im Umkreis von ..." bedeutet für mich aber schon einen gewissen
festgelegten radialen Maximalwert und nicht noch 10km Quadratzuschlag.

Micha
n.Olivier
2006-11-27 16:47:09 UTC
Permalink
Hi
Post by Helmut Hullen
Hallo, n.Olivier,
[...]
Post by Helmut Hullen
Post by n.Olivier
Post by Helmut Hullen
gesuchte Ort innerhalb eines Rechtecks oder Quadrats liegt) dürfte
erheblich schneller sein.
Die Erde ist nun mal kein Quadrat :-)
Ja und?
Welche Genauigkeit ist gefordert? "im Umkreis" ist nur eine von
etlichen möglichen Anforderungen.
Je nach lage des Quadrates hast du abweichungen
im Bereich von +20% bis -20% was bei 10 km mal 2 km sein können.
Post by Helmut Hullen
Post by n.Olivier
Und wie Niels schrieb, sollte die Formel kein für eine DB kein
Problem darstellen.
Technisch sicherlich unproblematisch. Ich vermute aber, dass die
erforderliche Rechenzeit erheblich grösser ist als bei einer (x+/-dx,
y+/-dy)-Suche, bei einer "BETWEEN"-Suche. Und es könnte sein, dass die
Rechenzeit auch ein Problem werden kann.
Dafür gibt es Indexe und weitere where-einschränkungen um aus
den z.B. für Deutschland ca. 20' DS mal auf möglichen eintausend
zu begrenzen und aus diesen dann die richtigen raus suchen.

Natürlich sollte man solche 'experimente' nicht unbedingt auf
einen SharedServer mit 500 anderen Domains versuchen :-)

gruß n.Olivier
--
Nachbagauer Olivier - www.nOlivier.com
www.reedb.com - Immobilien national & international
Webportal der Immobilien-Branche - www.Immofinder.de
Helmut Hullen
2006-11-27 17:54:00 UTC
Permalink
Hallo, n.Olivier,
Post by n.Olivier
Post by Helmut Hullen
Post by n.Olivier
Die Erde ist nun mal kein Quadrat :-)
Ja und?
Welche Genauigkeit ist gefordert? "im Umkreis" ist nur eine von
etlichen möglichen Anforderungen.
Je nach lage des Quadrates hast du abweichungen
im Bereich von +20% bis -20% was bei 10 km mal 2 km sein können.
Ja und? Was sind im speziellen Fall die speziellen Anforderungen?

Viele Grüße!
Helmut
n.Olivier
2006-11-27 21:13:57 UTC
Permalink
Hi
Post by Helmut Hullen
Hallo, n.Olivier,
Post by n.Olivier
Post by Helmut Hullen
Post by n.Olivier
Die Erde ist nun mal kein Quadrat :-)
Ja und?
Welche Genauigkeit ist gefordert? "im Umkreis" ist nur eine von
etlichen möglichen Anforderungen.
Je nach lage des Quadrates hast du abweichungen
im Bereich von +20% bis -20% was bei 10 km mal 2 km sein können.
Ja und? Was sind im speziellen Fall die speziellen Anforderungen?
Eine Umkreissuche und kein Zufallsergebnis.

Wenn sich dein Kunde (Besucher) auskennt und das erste mal
merkt, das A wohl dabei ist, aber B, wo seine Angebote sind
nicht, obwohl es näher liegt ...

Da sage ich nur entweder vernünftig oder gar nicht.
Halbfertige Lösungen die das falsche Ergebnis liefern
gibt es genug und die max. 0.5 sec mehr fallen auch nicht
ins gewicht, wenn der rest halbwegs vernünftig rüber kommt.

gruß n.Olivier
--
Nachbagauer Olivier - www.nOlivier.com
www.reedb.com - Immobilien national & international
Webportal der Immobilien-Branche - www.Immofinder.de
Helmut Hullen
2006-11-27 21:38:00 UTC
Permalink
Hallo, Jens,
Post by Jens Steinführer
ich habe ein Problem mit der MYSQL-Abfrage.
Zum Verständnis: ich möchte die Orte aus einer Tabelle lesen, die
sich z.B. 10km vom Ursprungsort befinden. Da vorhandene Systeme
sehr umfangreich sind (von den Berechnungen her,etc.), hab ich aus
der Radiussuche eine Quadratsuche gemacht (also 10 links, rechts,
oben und unten).
Da Du ja das Suchproblem eingebracht hast: wie genau muss die Suche
sein? Brauchst Du unbedingt "Umkreis", oder reicht "ungefähr 10 km von
irgendetwas entfernt"?

Viele Grüße!
Helmut
Jens Steinführer
2007-01-16 18:58:06 UTC
Permalink
Post by Helmut Hullen
Da Du ja das Suchproblem eingebracht hast: wie genau muss die Suche
sein? Brauchst Du unbedingt "Umkreis", oder reicht "ungefähr 10 km von
irgendetwas entfernt"?
Hallo Helmut,

ich hatte ja bereits geschrieben, dass die Suche jetzt soweit
funktioniert, wie ich es brauchte... es reichte eine "ungefähre"
Angabe... siehe www.sachsennetz.de (Ortssuche)

sorry, dass ich jetzt erst geschrieben hab, ich hatte damals das als
erledigt angesehen und nur per Zufall nun festgestellt, dass die
Diskussion noch muter weiter ging...

MfG
Jens

Loading...