SQL Arbeiten mit GeoDaten

gaunt

Lt. Commander
Registriert
Aug. 2007
Beiträge
2.016
Hi
habt ihr Erfahrung im Umgang mit Geo Daten?

Ich hab zwei Tabellen (jeweils mit ein paar Mio Einträgen) mit Orten und kann die nur über die Koordinaten matchen.
Also quasi nach dem Motto: "Wenn zwei Orten nur wenigen Meter auseinander liegen dann wirds wohl ein und der selbe Ort sein..."
Das würde ich bei ein paar wenigen Orten schon hinbekommen, aber ich brauchs bei den Mengen garnicht probieren, dass wird sehr (zu) lange laufen...

Jetzt gibts ja diverse Datenbanken (aktuell mysql) und Frameworks die auf die Bearbeitung von Geo Daten spezialisiert sind. Die kann ich natürlich alle der reihe nach durchprobieren, aber bis ich da fertig bin...

Ich wollte einfach mal fragen ob einer aus eigener Erfahrung Werkzeuge kennt mit denen ich einen solchen Abgleich in erträglicher Zeit hinbekommen kann. Im Idealfall natürlich OS.
 
Ich habe leider noch nicht damit gearbeitet, kenne aber die Möglichkeit, in SQL Server mit geografischen Daten zu arbeiten.
Das ganze versteckt sich hinter dem geography-Datentyp, mit dem du Koordinaten eintragen kannst:
http://msdn.microsoft.com/de-de/library/cc280766.aspx

Hier mal ein Praxisbeispiel, evtl. hilft es dir ja:
http://blogs.myfirstsharepoint.de/technikblog/aus-der-praxis-geodaten-in-sql-server

Mit der Express-Version von SQL-Server könntest du das mal ausprobieren.

Bei mysql habe ich leider keinerlei Erfahrung.
 
Zuletzt bearbeitet:
Ich selber studiere Geoinformatik und komme da das eine oder andere mal mit Geodaten in Berührung ;)
Bzgl. Datenbanken und Geodaten: Da kommt man um eine Sache gearnicht drum herum: postgreSQL Datenbank mit PostGIS Erweiterung. Letzteres bringt dir wirklich alle nötigen Funktionen und Operationen, die man sich nur vorstellen kann.

In dem Kontext kann ich dir auch wärmestens cartoDB ans Herz legen: http://cartodb.com/
Viel einfacher, Karten aus Datenbanken zu erstellen, geht es fast nicht.
 
Ist leicht am Thema vorbei, aber Entfernung zwischen zwei Koordinaten auf der Erdkugel: acos(sin($x1=deg2rad($x1))*sin($x2=deg2rad($x2))+cos($x1)*cos($x2)
*cos(deg2rad($y2) - deg2rad($y1)))*(6378.137);
Sprich wenn deine DB die wichtigsten trigonometrischen Funktionen beherrscht, könnte man zumindest mal testen, wie weit man damit kommt. So oder so muss man aber jeden Punkt mit jedem abgleichen, das wird schon a weng dauern.
 
Hi
sorry, hatte en bissel um die Ohren weshalb ich hier nicht zu gekommen bin. Jetzt aber schon;-)

Also:
- Postgres mit PostGIS wäre wohl das Mittel der Wahl, um damit aber sinnvoll arbeiten zu können müsste ich mich erst einarbeiten und dazu fehlt mir aktuell die Zeit. Aber vielleicht gucke ich mir das mal privat an. Jetzt mussten schnell Ergebnisse her.
- MS SQL geht leider nicht. Ne kommerzielle Lösung ist aktuell nicht erwünscht.
- MySQL bietet auch ne GIS Erweiterung. Ist aber noch nicht so ausgereift wie PostGIS. Hier gillt ähnliches wie für PostGIS. Zu hoher Aufwand im vorfeld.

Wie gelöst?
Da ich nur Orte matchen muss die nahe beieinander liegen hab ich zunächst nur für Orte im gleichen Land den Abstand berechnet mit einer mathematisch etwas weniger aufwändigen Funktion als die von Mambokurt. Etwas ungenauer, vor allem wenn die Orte weit auseinander liegen, aber das spielt bei mir keine große Rolle.
Code:
select 
	(sqrt(
		((111.3 * cos((t1.Lat_m + 	?		) / 2 * 0.01745) * (t1.Lon_m - 		?		)) * 
	 	(111.3 * cos((t1.Lat_m + 	?		) / 2 * 0.01745) * (t1.Lon_m - 		?		))) + 
		((111.3 * (t1.Lat_m - 		?		)) * 
		(111.3 * (t1.Lat_m - 		?		))))*1000) as entfernung
Die Fragezeichen werden durch die entsprechenden Werte des zweiten Ortes ersetzt. Dann alle Abstände zu allen Stäten im geleichen Lande ermitteln und die kürzeste Entfernung isses dann.
Laufzeit gut eine Woche bei 100% Prozessorauslastung:freak:

Hab dann noch Hilfsspalten angelegt um die Koordinaten zu "kürzen". Die gekürzten Koordinaten hab ich im where abgefragt. Ich hab also im Endefekt einen Teil der Prozessorlast in IO Last umgewandelt.
Und siehe da: Laufzeit unter einer Stunde :king:

THX
Die GIS Komponenten schaue ich mir bei Gelegeneheit mal an.
 
Zurück
Oben