Hallo zusammen! Ich habe hier eine Datenbank mit Postleitzahlen und deren GEO-Koordinaten. Nun muss ich eine Kundenanfrage aus einer bestimmten PLZ mit hinterlegten Firmenkunden und deren Postleitzahlen abgleichen (also welche Firma diese Anfrage bedienen kann). Die Firmen haben allerdings von der Firmensitz-PLZ einen variabel eingeschränkten Betätigungsfeldradius (als Kilometer-Angabe) hinterlegt, von dem aus sie arbeiten (z.b. 50km). Es gibt folgendes Problem zu lösen: Nun müsste sich eine Schnittmenge von Firmen ergeben, die Aufgrund ihrer Eingrenzung zu dieser Anfrage passen. Ich bekomme es allerdings nicht hin von Seiten der Anfrage die passenden Firmen aufgrund ihrer hinterlegten Umkreise zuzuteilen. Zudem muss das ganze Ressourcenschonend sein, ohne etliche Datenbankabfragen loszutreten. Hat jemand Vorschläge? Vielen Dank!
Alfred Schleier schrieb: > Hallo zusammen! > Ich bekomme es allerdings nicht hin von Seiten der Anfrage die passenden > Firmen aufgrund ihrer hinterlegten Umkreise zuzuteilen. Zudem muss das > ganze Ressourcenschonend sein, ohne etliche Datenbankabfragen > loszutreten. > > Hat jemand Vorschläge? Vielen Dank! ich verstehe das Problem nicht ganz. Es geht dir also nur um den Abstand von 2 GEO-Koordinaten?
Kannst du den Spiess nicht umdrehen und für jede Firma anlegen, welche PLZ sie bedienen kann? Wenn du zu viele Firmen hast, dann kann das natürlich immer noch saulangsam werden. Ich seh da aber ehrlich gesagt nicht viele andere Möglichkeiten, als eine Hilfsstruktur wie zb einen Quadtree basierend auf den Koordinaten aufzubauen, der die Firmenauswahl schon mal auf sehr hohem Niveau in kleinere Einheiten aufteilt. Wenn die erste Ebene des Quadtree aus dem gesamten Bundesgebiet schon mal 3/4 aufgrund der Koordinaten ausschliesst, dann ist das schon mal eine ganze Menge.
aus Sicht der Firma sehr einfach: Match laufen lassen, was die PLZ abgleicht. Problem: Aus Sicht der Anfrage gibt es keinen vordefinierten Umkreis und ich kann die Firmen nicht zuordnen ohne eine Flut von Abfragen auszulösen.
Was für ein RDBMS ist es denn? Ziemlich viele haben inzwischen räumliche Erweiterungen, damit ist dann trivial diese Anfragen schnell zu beantworten. Ansonsten könnte man das Gebiet mit einem Gitter (z.B. 10km) überziehen. Für jede Firma berechnest du im voraus, welche Gitterkästchen sich mit ihrem Tätigkeitsbereich überscheiden. Dann fragst du ab, welche Firmen in dem Kästchen arbeiten in dem der Kunde sitzt und machst dann noch eine Abstandsberechnung. Das passt alles in eine WHERE Klausel.
Einfach nur aus der PLZ selbst dürfte sich so etwas algorithmisch kaum ableiten lassen - man betrachte Berlin, da berühren sich beispielsweise 10825, 10715, 12161 und 14197 - und das gilt alles noch als Innenstadt (Wilmersdorf und Schöneberg). Die "Systematik" bei der Vergabe der Postleitzahlen dürfte auch andernorts vergleichbar wirr sein. Mit dem Thema hat man sich im Rahmen der OpenGeoDB beschäftigt: http://opengeodb.org/wiki/OpenGeoDB_-_Umkreissuche
> Die "Systematik" bei der Vergabe der Postleitzahlen dürfte auch > andernorts vergleichbar wirr sein. Macht ja nix. Man legt einmal für jede Partnerfirma eine Liste der PLZ an, die sie bedienen kann (wenn sie das selber macht oder überarbeitet, kann die sogar beliebige Form haben), und damit ist man schon fertig. Prüfen ob die Anfrage-PLZ in der Liste vorkommt, wird man ja noch gerade so hinkriegen. Aber warum einfach, wenn man höhere Geometrie dazu ins Spiel bringen kann. Gruss Reinhard
Reinhard Kern schrieb: > Aber warum einfach ... Hängt vom Mengengerüst ab. Hast du 500-tausend Firmen und suchst du jene, in deren Einzugsbereich eine bestimmte PLZ vorkommt, so dauert das dann schon ein Weilchen, die möglichen Kandidaten zu finden. Bei 50 oder 100 Firmen spielt das hingegen kaum eine große Rolle.
Du machst 2 Indices einer für den Breiten und einer für den Längengrad. Dann sortierst du alle die aus, die vom Breiten ODER Längegrad schon zu weit weg sind. Übrig bleiben die Firmen innerhalb eines Quadrat mit Kantenlänge 2*Radius um deinen Standort. Die holst du dir und berechnest den tatsächlichen Abstand, sortierst das Ergebnis und nimmst den Nächsten.
Karl Heinz schrieb: > Bei 50 oder 100 Firmen spielt das hingegen kaum eine große Rolle. Vor allem bietet das Verfahren die volle Freiheit, es gibt da draussen alle möglichen Verträge: Kunden im Umkreis von x km, Kunden im Bundesland Y, Kunden im PLZ-Bereich Z, Kunden im schwäbischen Sprachraum... Wer das Geschäft mit Handelsvertretungen kennt, weiss was ich meine. Gruss Reinhard
Nachtrag: Benutzt man Mengen, so benötigt man 12,5 kB Speicherplatz pro Partnerfirma. Das sollte bei heutiger Speicherausstattung nicht das Problem sein. Wer hat schon 500000 Partnerfirmen? Gruss Reinhard
wie kommst du auf 12,5kB? Und das mit der Partnerfirma kam ja nicht vom Threadersteller. Für ne Deutschlandweite DB können da sicherlich paar (hundert)tausende Einträge zusammenkommen
Eigentlich einfach: Aus den Postleitzahltabelle die zu zugehörigen geografischen Koordinaten raussuchen. einfache Version: Die Differenzen der geografischen Koordinaten werden nach Pythagoras quadriert, addiert und dann daraus die Wurzel gezogen. Multipliziert man das Ergebnis mit 111km, so erhält man grob die Entfernung zwischen den Orten. Mittlerer Version: Weil oben das Zusammenlaufen der Längengrade nicht berücksichtigt wurde, ist vor dem Quadrieren die Differenz der Längengrade mit cos(Mittelwert der Längengrade) zu multiplizieren. Dann weiter wie oben. Anspruchsvollere Version: Anwendung der Seitenkosinussatzes, das ist Mathematik. Siehe: http://www.kompf.de/gps/distcalc.html Joe
Joe schrieb: > einfache Version: > > Die Differenzen der geografischen Koordinaten werden nach Pythagoras > quadriert, addiert und dann daraus die Wurzel gezogen. > Multipliziert man das Ergebnis mit 111km, so erhält man grob die > Entfernung zwischen den Orten. Die EDV Version. Man zieht nicht die Wurzel sondern hat bereits die Quadrate zu Vergleichszwecken abgespeichert. sqrt(a) < sqrt(b) genau dann, wenn a < b Genau genommen, wenn fabs(a) < fabs(b). Aber so dämlich wird ja wohl doch keiner sein, negative Entfernungen einzugeben. der Rest: uninteressant. Wenn eine Firma einen Kunden ablehnt, weil der 500Meter ausserhalb des Einzugsbereichs wohnt, dann lebt die nicht lange. Zudem ist mit der PLZ ja keine bestimmte Position verknüpft, sondern ein Mittelwert des PLZ-Gebietes. Genauer als dieses braucht man daher nicht rechnen. ALl das löst aber nicht das Problem, dass bei "Wer liefert was?" im dt. Bundesgebiet 500-tausend Firmen abgelegt sind, die man ein wenig cleverer durchsuchen sollte als einfach nur linear einen nach dem anderen. Das Problem ist nicht ein geometrisches Problem sondern ein algorithmisches bzw. eines der Datenstrukturen.
:
Bearbeitet durch User
Reinhard Kern schrieb: > Macht ja nix. Man legt einmal für jede Partnerfirma eine Liste der PLZ > an, die sie bedienen kann (wenn sie das selber macht oder überarbeitet, > kann die sogar beliebige Form haben), und damit ist man schon fertig. Aha. Weißt Du, wieviele Postleitzahlen alleine Berlin hat?
Rufus Τ. Firefly schrieb: > Reinhard Kern schrieb: >> Macht ja nix. Man legt einmal für jede Partnerfirma eine Liste der PLZ >> an, die sie bedienen kann (wenn sie das selber macht oder überarbeitet, >> kann die sogar beliebige Form haben), und damit ist man schon fertig. > > Aha. Weißt Du, wieviele Postleitzahlen alleine Berlin hat? Macht nix. Das kann ja der Rechner machen. Ackert der halt mal eine Nacht durch, anstatt Tee zu trinken und Viren zu scannen. Er hat ja eine PLZ Tabelle, aus der er die geografischen Daten ermitteln kann. Aber so recht finde ich die daraus resultierende Suche nicht sonderlich elegant. Sortierung nach einer Koordinate und Einteilung der Firmen in die jeweilige Bins gefällt mir schon besser. Aus der Benutzer-PLZ kriegt man die Koordinate. Daraus wiederrum erhält man den zuständigen Bin und in diesem Bin gibt es eine LIste aller Firmen, die diesen Bin zumindest potentiell bedienen. Über diese nun kleinere Anzahl an Kandidaten noch ein geometrischer Vergleich und den besten davon finden. Das sollte eigentlich recht schnell gehen.
Ein dictionary/hashmap/Datenbanktabelle/wasauchimmer, das zu jeder Kunden-PLZ (es gibt nur ~29000) eine Liste der möglichen Firmen liefert, muss nur einmal berechnet und lediglich beim Eintrag einer neuen Firma (das sollte viel seltener vorkommen als eine Abfrage) ergänzt werden.
:
Bearbeitet durch User
A. B. schrieb: > wie kommst du auf 12,5kB? Eine Menge wird durch ein Bit pro Element dargestellt, alle deutschen PLZ ergeben also in Mengendarstellung 100 kBit = 12,5 kByte. Um festzustellen, ob Firma X im PLZ-Gebiet Y aktiv ist, stellt die "in"-Funktion fest, ob das Ynte Bit gesetzt ist. > Und das mit der Partnerfirma kam ja nicht vom Threadersteller. Doch habe ich so verstanden: Alfred Schleier schrieb: > Nun muss ich eine Kundenanfrage aus einer bestimmten PLZ mit > hinterlegten Firmenkunden und deren Postleitzahlen abgleichen Das heisst meinem Verständnis nach, er hat eine Anzahl Vertragspartner (Firmenkunden), die jeweils ein bestimmtest Gebiet bedienen, und nun muss er bei einer Anfrage anhand der PLZ rausfinden, wer davon in Frage kommt. Lohnt sich aber nicht weiter zu diskutieren, wurde ja schon allgemein als unbrauchbar abgelehnt. Gruss Reinhard
Da das Problem ja mit der Anfrage an sich zusammenhängt geht wohl nur eine Referenzlösung. Ich kann nicht abfragen was ich zum Abfragezeitpunkt nicht weiss.
Ich werf da einfach mal ein:
Das alles bringt nichts, da die km Umkreis nicht der Fahrlänge
entspricht.
Wenn man das vernachlässigen kann ist das Problem recht einfach zu
lösen:
du suchst ob eine Adresse innerhalb eines Kreises mit Radius x km um die
Adresse einer Firma liegt.
Die Laufzeit ist linear mit Anzahl der Firmen. Du musst nur bei anlegen
einer neuen Firma die Koordinaten ermitteln und den Radius eintragen.
Dann filterst du deine Firmen mit ermittelten Koordinaten des Kunden mit
dem Ansatz hier.
if( (x_kreis - x_P)*(x_kreis - x_P) + (y_kreis - y_P)*(y_kreis - y_P) <
radius*radius ) {
// dann ist der Punkt strikt innerhalb (nicht auf dem Rand)
...
}
Ich weiß allerdings nicht ob das als when clause auch geht.
Das ganze dann noch als minimum oder top 10
die Koordinaten kannst du mit
https://developers.google.com/maps/documentation/geocoding/?hl=de
erhalten
Alfred Schleier schrieb: > GEO-Koordinaten. > Nun muss ich eine Kundenanfrage aus einer bestimmten PLZ mit > hinterlegten Firmenkunden und deren Postleitzahlen abgleichen (also > welche Firma diese Anfrage bedienen kann). Die Firmen haben allerdings > von der Firmensitz-PLZ einen variabel eingeschränkten > Betätigungsfeldradius (als Kilometer-Angabe) hinterlegt, von dem aus sie > arbeiten (z.b. 50km). Und genau deshalb sind deine Geokoordinaten wertlos weil keiner Luftlinie zum Kunden fliegt sondern nur die Entfernung per Strasse entscheidend ist. Du musst deine GEO-Koordinaten in Entfernungsangaben umrechnen, damit du sowas wie einen Routenplaner hast oder besser du nutzt gleich einen entsprechenden wie z.B. von google maps, da gibts nat. ne API. Damit hast du dann gleich auch noch Einbahnstrassen,... aktuelle Verkehrslage,... mit erschlagen und das ist dann auch exakt und nicht so Pi-Mal-Daumen geschätzt wie mit dem Koordinatenmist, das macht doch heute kein Mensch mehr so.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.