![]() Mailinglisten-Archive |
Hallo Gerd, das h�rt sich sehr interessant an. Nach meiner Erfahrung steckt in der Fl�chenzuordnung zur Koordinate ein rechenaufw�ndiges Gesch�ft. Eventuell w�re eine vereinfachende Annahme der Ansatzpunkt um den Rechenaufwand und damit die Suchzeit zu verk�rzend. Ohnehin bezweifle ich, dass der Fl�chenzuordnungsalgorithmus in der Query Platz finden wird. Mein Ansatz w�re: 1. Berechne von jeder Fl�che die Mittelpunktskoordinate. 2. Mit Deiner Datenbankabfrage suchst Du die TOP 20 der Zielkoordinate n�chst gelegenen Grundst�cke 3. Bei diesen checkst Du dann, ob die Zielkoordinate in der Fl�che drinnen liegt. Das sollte z�gig von statten gehen. Ein anderer Ansatz f�llt mir gerade noch ein: 1. Speichere Alle Kanten der Grundst�cke als Strecken mit den Koordinaten X1/Y1 , X2/Y2. Merke Dir dazu, ob die Fl�che jeweils links/rechts/oben/unten zur Strecke liegt. 2. Zus�tzlich speicherst Du bei der Strecke die ID der zugeh�rigen Fl�che. 3. Wenn Du per SELECT �ber die Tabelle dr�ber huschst checkst Du zu jedem Streckenrecord, ob f�r die Zielkoordinate die Bedingung oben/rechts usw. erf�llt ist. Das ist dann nur noch kleine Geometrie. 4. Da Du ja �ber die ID wei�t, zu welcher Fl�che die Strecke geh�rt, kannst Du pr�fen, ob alle Strecken richtig zur Zielkoordinate liegen. Hier sollte man die Daten in Reihenfolge der ID verarbeiten. Sobald eine Srecke nicht passt, kann man den Rest des Datenstroms zur ID �berspringen. Und man merkt soforrt, ob alle Strecken zur ID die Bedingung erf�llen. So, das gen�gt zum fr�hen Samstag morgen. Hoffe, die Br�tchen schmecken jetzt noch und ich habe Dich nicht zu sehr ins Gr�beln gebracht. Beste Gr��e, Hans-J�rgen -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive