Re: [Talk-de] Algorithmus für effiziente PLZ-Geb iete gesucht
Marcus Wolschon schrieb: An Voronoi-Diagramme hab ich schon gedacht. Mittels des Divide and Conquer -Ansatzes sollte das gut zu parallelisieren sein. Nur wie macht man das ohne einen großteil aller Punkte welche eine PLZ haben mehrfach in den Speicher zu laden oder gleich nochmal Speicher in der Größenordnung dieser Punktmenge zu benötigen? Die Bonner Geoinformatiker können vielleicht helfen: http://www.ikg.uni-bonn.de/vorlesungsarchiv/Diskrete_Mathematik_II/Folien/neuefolien_bmbf/druck1/matheII_6_druck1.pdf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Algorithmus für effiziente PLZ-Geb iete gesucht
On Tue, 27 Oct 2009 13:19:24 +0100, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Marcus Wolschon schrieb: An Voronoi-Diagramme hab ich schon gedacht. Mittels des Divide and Conquer -Ansatzes sollte das gut zu parallelisieren sein. Nur wie macht man das ohne einen großteil aller Punkte welche eine PLZ haben mehrfach in den Speicher zu laden oder gleich nochmal Speicher in der Größenordnung dieser Punktmenge zu benötigen? Die Bonner Geoinformatiker können vielleicht helfen: http://www.ikg.uni-bonn.de/vorlesungsarchiv/Diskrete_Mathematik_II/Folien/neuefolien_bmbf/druck1/matheII_6_druck1.pdf Wie Voronoi-Diagramme gemeinhin konstruiert werden habe ich wie jeder Dipl.Inf gelernt. Momentan bevorzuge ich den Weg einfach alle Punkte die eine PLZ im richtigen Staat haben zu sammeln und zu dem abgefragten Punkt einfach den mit geringster Entfernung von PostGIS heraus suchen zu lassen. Ist garnicht nötig wie Polygone im Vorfeld zu berechnen. Schliesslich werden sie nie als solche angezeigt. Gruss, Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Algorithmus für effiziente PLZ-Geb iete gesucht
marcus.wolsc...@googlemail.com schrieb: Ist garnicht nötig wie Polygone im Vorfeld zu berechnen. Schliesslich werden sie nie als solche angezeigt. Wieso eigentlich nicht? Ich würde das zum Debuggung sehr sinnvoll finden. So könnte man die Daten nämlich auch mit anderen Karten überlagern und Fehler finden. Solange man die anderen Daten nicht übernimmt, ist es okay. Könntest Du es dahingehend erweitern oder wäre es zu umständlich? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Algorithmus für effiziente PLZ-Geb iete gesucht
2009/10/26 Tobias Wendorff tobias.wendo...@uni-dortmund.de: Am Mo, 26.10.2009, 14:16 schrieb Philipp Matthias Hahn: Und jetzt bitte nicht dir Frage, was ein Algorithmus oder eine konvexe Hülle ist :-) Nein, nein ;-) Ich habe aufgrund der Überschneidungen nur noch nie konvexe Hüllen, sondern fasst immer nur Thiessen verwendet. An Voronoi-Diagramme hab ich schon gedacht. Mittels des Divide and Conquer -Ansatzes sollte das gut zu parallelisieren sein. Nur wie macht man das ohne einen großteil aller Punkte welche eine PLZ haben mehrfach in den Speicher zu laden oder gleich nochmal Speicher in der Größenordnung dieser Punktmenge zu benötigen? Die alternative Berechnung über die untere Konvexe Hülle hat die Konvexe Hülle bereits als Teilschritt bevor nochmal eine teure O(n)-Transformation gemacht wird. Sweep meine ich, scheidet völlig aus wegen der Sortierung. Da lass ich mich aber gerne von Leuten mit mehr Erfahrung in PostGIS (der eingesetzten Datenbank) korrigieren. Dann die einen spatial-Index von Points für eine Sortierung eines Suchergebnisses nach der Lat-Achse nutzen wenn die Suche über ein String-Feld geht (also nicht über den Index selbst gesucht wird)? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
