2010-08-23 14 views
6

Dies ist das erste Mal, dass ich GeoDjango mit PostGIS verwende. Nach der Installation und einigen Tests, bei denen alles gut läuft, mache ich mir Gedanken über die Abfrageleistung, wenn Tabellenzeilen wachsen.Brauchen Sie Leistung auf PostGIS mit GeoDjango

Ich spare in einem Geometriepunkt Längen- und Breitengrade, die ich von Google Geokodierung (WGS84 oder SRID 4326) bekomme. Mein Problem ist, dass Abstandsoperationen in meiner Anwendung sehr häufig sind. Ich muss oft in der Nähe von Punkten von einem Wahrzeichen kommen. Geometrie-Mathematik ist sehr komplex, und selbst wenn ich einen räumlichen Index habe, wird es in der Zukunft wahrscheinlich zu lange dauern, mehr als 1000 Punkte in einem nahegelegenen Gebiet zu haben.

Gibt es eine Möglichkeit, diesen Geometrietyp so zu projizieren, dass die Entfernungsoperationen schneller ausgeführt werden? Kennt jemand eine Django-Bibliothek, die eine Google-Karte mit einigen dieser Punkte darstellen kann?

Gibt es Hinweise, wie Sie räumliche Abfragen auf GeoDjango beschleunigen können?

+1

Nur um zu verdeutlichen, haben Sie tatsächlich Leistungsprobleme mit PostGIS? Wenn Sie nur darüber besorgt sind, was passieren könnte, widerstehen Sie einer vorzeitigen Optimierung! Menschen haben gute Ergebnisse mit Abfragen wie Ihre mit Tabellen mit vielen Millionen von Datensätzen. Mehr über Distanzanfragen: http://www.bostongis.com/?content_name = postgis_tut02 # 21 – tcarobruce

+0

Nun, ich bin mir nicht sicher, ob ich diese vorzeitige Optimierung nennen würde (obwohl ich noch keine Leistungsprobleme hatte). Ich muss einfach wissen, dass GeoDjango bei Bedarf der Herausforderung gewachsen ist. Ich kenne PostGIS und wie man Distanzabfragen mit && und Überlappungsboxen verbessert, aber nutzt GeoDjango das? Auf der anderen Seite, bin ich nicht pingelig mit Präzision, also sollte ich nicht Geometrie verwenden, weil es einen Preis hat. – maraujop

Antwort

0

Im Allgemeinen erstellt und verwendet GeoDjango räumliche Indizes für Geometriesäulen.

Für eine Anwendung, die hauptsächlich Entfernungen zwischen Punkten behandelt, kann die Geography type (in PostGIS 1.5 eingeführt und von GeoDjango unterstützt) eine gute Lösung sein. GeoDjango sagt, es gibt "viel bessere Leistung bei WGS84 Distanzabfragen" [link].

+1

Das stimmt, wie Sie in http://docs.djangoproject.com/en/1.2/ref/contrib/gis/model-api/#spatial-index GeometryField.spatial_index -> Standard auf True nachlesen können. Erstellt einen räumlichen Index für das angegebene Geometriefeld. Django unterstützt Geografie-Typ seit der letzten stabilen Version 1.2.1, also ist es ziemlich neu. In der Dokumentation können Sie auch lesen: Weil Geographie Berechnungen mehr Mathematik beinhalten: http://docs.djangoproject.com/en/dev/ref/contrib/gis/model-api/#selecting-an-srid So was ich frage, ist Geografie wirklich eine gute Passform? wird es richtig skalieren? – maraujop

3

Wenn Sie Ihren Arbeitsbereich in eine Kartenprojektion einpassen können, wird das immer schneller, da weniger Matheaufrufe für Entfernungsberechnungen erforderlich sind. Wenn Sie jedoch über wirklich globale Daten verfügen, sollten Sie es auf keinen Fall auslassen: Verwenden Sie geography. Wenn Sie nur kontinentale USA Daten haben, verwenden Sie etwas wie EPSG: 2163 http://spatialreference.org/ref/epsg/2163/

Je eingeschränkter Ihr Arbeitsbereich ist, desto genauere Ergebnisse erhalten Sie in einer Kartenprojektion. Sehen Sie die Projektionen der Staatsebene für stark eingeschränkte, genaue Projektionen für regionale Gebiete in den USA. Oder UTM-Projektionen für größere subnationale Regionen.

+0

Ich verstehe die Projektierung ist schneller, aber ich verwalte spanische Geodaten und bin mir nicht sicher, wie ich es in GeoDjango umwandeln, speichern und verarbeiten kann. Zur gleichen Zeit, nicht sicher, ob Punkte von Google in SRID 4326 oder EPSG 900913 – maraujop

+1

angegeben werden Die Google API gibt zurück und konsumiert Koordinaten in EPSG: 4326. Für ein projiziertes System in Spanien versuchen Sie EPSG: 25831. –

2

Ich recherchiere zu diesem Thema. Soweit ich gefunden habe, sind die Koordinaten, die Sie von der Geopy-Bibliothek erhalten, im SRID 4326-Format, so dass Sie sie ohne Probleme in einem Geometriefeldtyp speichern können. Dies wäre ein Beispiel für eine GeoDjango Modell Geometrie:

class Landmark(models.Model): 
    point = models.PointField(spatial_index = True, 
          srid = 4326, 
          geography = True) 

    objects = models.GeoManager() 

By the way, sehr vorsichtig sein, Länge/Breite auf die PointField Pass, in genau dieser Reihenfolge. Geopy gibt die Längen-/Breitenkoordinaten zurück, also müssen Sie sie umkehren.

Für die Umwandlung von Punkten in einem Koordinatensystem in ein anderes können wir GEOS mit GeoDjango verwenden. Im Beispiel werde ich einen Punkt in 4326 zu den berühmten Google Projektion 900913 verwandeln:

from django.contrib.gis.geos import Point 
punto = Point(40,-3) 
punto.set_srid(900913) 
punto.transform(4326) 
punto.wkt 
Out[5]: 'POINT (0.0003593261136478 -0.0000269494585230)' 

So können wir Koordinaten in Projektionssystemen speichern können, die eine bessere Leistung Mathematik haben. Zum Anzeigen von Punkten in einer Google-Karte in der Admin-Site-Oberfläche. Wir können this great article verwenden.

Ich habe beschlossen, mit Geographietypen fortzufahren, und ich werde sie in Zukunft konvertieren, falls ich die Leistung verbessern muss.