2010-08-23 14 views
6

Questa è la prima volta che sto utilizzando GeoDjango con PostGIS. Dopo l'installazione e alcuni test con tutto ciò che funziona bene, mi preoccupo delle prestazioni della query quando le righe della tabella aumenteranno.bisogno di prestazioni in PostGIS con GeoDjango

sto risparmiando in una geometria longitudini e latitudini punto che ricevo da Google geocoding (WGS84, o SRID 4326). Il mio problema è che le operazioni a distanza sono molto comuni nella mia applicazione. Spesso ho bisogno di avvicinarmi ai luoghi da un punto di riferimento. La matematica geometrica è molto complessa, quindi anche se ho un indice spaziale, probabilmente ci vorrà troppo tempo in futuro con più di 1000 spot in un'area vicina.

Quindi non v'è alcun modo per proiettare questo tipo di geometria di fare operazioni a distanza più veloce? qualcuno conosce una libreria Django che può rendere una mappa di Google contenente alcuni di questi punti?

Eventuali consigli su come velocizzare le query spaziali su GeoDjango?

+1

Giusto per chiarire, stai riscontrando problemi di prestazioni con PostGIS? Se sei solo preoccupato di ciò che potrebbe accadere, resisti all'ottimizzazione prematura! Le persone hanno buoni risultati con query come la tua che utilizzano tabelle con molti milioni di record. Altro su query a distanza: http://www.bostongis.com/?content_name = postgis_tut02 # 21 – tcarobruce

+0

Beh, non sono sicuro che chiamerei questa ottimizzazione prematura (anche se non ho ancora avuto problemi di prestazioni). Ho semplicemente bisogno di sapere che GeoDjango sarà all'altezza della sfida quando necessario. Conosco PostGIS e come migliorare le query a distanza utilizzando le caselle && e overlap, ma ad esempio GeoDjango usa questo? D'altra parte, non sono molto esigente con precisione, quindi non dovrei usare la geometria, perché ha un prezzo. – maraujop

risposta

0

Generalmente, GeoDjango creerà e utilizzerà indici spaziali su colonne geometria all'occorrenza.

Per un'applicazione che si occupa principalmente delle distanze tra i punti, lo Geography type (introdotto in PostGIS 1.5 e supportato da GeoDjango) può essere una buona soluzione. GeoDjango dice che offre "prestazioni molto migliori sulle query di distanza WGS84" [link].

+1

Questo è vero, come puoi leggere in http://docs.djangoproject.com/en/1.2/ref/contrib/gis/model-api/#spatial-index GeometryField.spatial_index -> Defaults su True. Crea un indice spaziale per il campo della geometria specificato. Django supporta il tipo di geografia dall'ultima versione stabile 1.2.1 quindi è piuttosto nuovo. Nei documenti puoi anche leggere: Poiché i calcoli geografici implicano più matematica: http://docs.djangoproject.com/en/dev/ref/contrib/gis/model-api/#selecting-an-srid Quindi quello che sto chiedendo è che la geografia sia davvero una buona idea? scalerà correttamente? – maraujop

3

Se puoi adattare la tua area di lavoro a una proiezione cartografica, sarà sempre più veloce, poiché sono necessarie meno chiamate matematiche per operazioni come i calcoli della distanza. Tuttavia, se si dispone di dati veramente globali, si consiglia di utilizzarlo: utilizzare la geografia. Se si dispone solo di dati continentali USA, utilizzare qualcosa come EPSG: 2163 http://spatialreference.org/ref/epsg/2163/

Più l'area di lavoro è vincolata, più i risultati sono precisi che si possono ottenere in una proiezione cartografica. Vedere le proiezioni del piano di stato per proiezioni estremamente limitate e precise per le aree regionali negli Stati Uniti. O proiezioni UTM per le più grandi regioni sub-nazionali.

+0

Capisco che la proiezione sia più veloce, ma sto gestendo i geodati spagnoli e non sono sicuro di come trasformarlo, archiviarlo ed elaborarlo in GeoDjango. Allo stesso tempo, non sono sicuro che i punti dati da Google siano in SRID 4326 o EPSG 900913 – maraujop

+1

L'API di Google restituisce e utilizza le coordinate in EPSG: 4326. Per un sistema progettato in Spagna, prova EPSG: 25831. –

2

Sono alla ricerca su questo argomento. Per quanto ho trovato, le coordinate ottenute dalla libreria di geopy sono in formato SRID 4326, quindi è possibile memorizzarle senza problemi in un campo di geometria. Questo potrebbe essere un esempio di un modello GeoDjango utilizzando la geometria:

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

    objects = models.GeoManager() 

proposito, essere molto attenti a passare longitudine/latitudine alla PointField, in questo ordine esatto. geopy restituisce le coordinate di latitudine/longitudine, quindi dovrai invertirle.

Per trasformare i punti in un sistema di coordinate in un altro, possiamo utilizzare GEOS con GeoDjango. Nell'esempio mi trasformare un punto nel 4326 al famoso di proiezione Google 900913:

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)' 

In questo modo siamo in grado di memorizzare le coordinate in sistemi di proiezione, che avrà una migliore matematica prestazioni. Per mostrare i punti in una mappa di Google nell'interfaccia del sito di amministrazione. Possiamo usare this great article.

Ho deciso di andare avanti con i tipi di geografia e li convertirò in futuro, nel caso avessi bisogno di migliorare le prestazioni.