2010-08-23 15 views
6

Esta es la primera vez que uso GeoDjango con postGIS. Después de la instalación y algunas pruebas con todo funcionando bien, me preocupa el rendimiento de las consultas cuando las filas de las tablas crecerán.Necesita rendimiento en postGIS con GeoDjango

Estoy guardando en un punto de geometría las longitudes y latitudes que obtengo de la geocodificación de Google (WGS84 o SRID 4326). Mi problema es que las operaciones a distancia son muy comunes en mi aplicación. A menudo necesito llegar a puntos cercanos a un punto de referencia. Las matemáticas de geometría son muy complejas, por lo que incluso si tengo un índice espacial, probablemente llevará demasiado tiempo en el futuro tener más de 1000 puntos en un área cercana.

¿Hay alguna manera de proyectar este tipo de geometría para hacer operaciones de distancia más rápido? ¿Alguien conoce una biblioteca de Django que pueda mostrar un mapa de Google que contenga algunos de estos puntos?

¿Algún consejo sobre cómo acelerar las consultas espaciales en GeoDjango?

+1

Solo para aclarar, ¿está experimentando problemas de rendimiento con PostGIS? Si solo está preocupado por lo que podría pasar, ¡resista la optimización prematura! La gente tiene buenos resultados con consultas como la suya usando tablas con muchos millones de registros. Más sobre consultas a distancia: http://www.bostongis.com/?content_name = postgis_tut02 # 21 – tcarobruce

+0

Bueno, no estoy seguro de llamar a esta optimización prematura (aunque todavía no he tenido problemas de rendimiento). Simplemente necesito saber que GeoDjango estará a la altura del desafío cuando sea necesario. Sé postGIS y cómo mejorar las consultas de distancia usando && y cuadros de superposición, pero, por ejemplo, GeoDjango usa esto? Por otro lado, no soy muy quisquilloso con precisión, así que no debería usar geometría, porque tiene un precio. – maraujop

Respuesta

0

En general, GeoDjango creará y usará índices espaciales en columnas geométricas cuando corresponda.

Para una aplicación que trata principalmente con distancias entre puntos, el Geography type (introducido en PostGIS 1.5 y compatible con GeoDjango) puede ser una buena opción. GeoDjango dice que ofrece "mucho mejor rendimiento en consultas de distancia WGS84" [link].

+1

Eso es cierto, como puede leer en http://docs.djangoproject.com/en/1.2/ref/contrib/gis/model-api/#spatial-index GeometryField.spatial_index -> El valor predeterminado es True. Crea un índice espacial para el campo de geometría dado. Django es compatible con el tipo de geografía desde la última versión estable 1.2.1, por lo que es bastante nuevo. En los documentos también puede leer: Debido a que los cálculos de geografía implican más matemáticas: http://docs.djangoproject.com/en/dev/ref/contrib/gis/model-api/#selecting-an-srid Entonces lo que estoy preguntando es si la geografía realmente encaja bien ¿Escalará correctamente? – maraujop

3

Si puede ajustar su área de trabajo en una proyección de mapa, siempre será más rápido, ya que hay menos llamadas matemáticas necesarias para cosas como cálculos de distancia. Sin embargo, si tiene datos realmente globales, cópialos: use geografía. Si solo tiene datos de EE. UU. Continentales, use algo como EPSG: 2163 http://spatialreference.org/ref/epsg/2163/

Cuanto más restringida sea su área de trabajo, más resultados precisos obtendrá en una proyección de mapa. Consulte las proyecciones del plano estatal para proyecciones precisas y muy limitadas para áreas regionales en los EE. UU. O proyecciones UTM para regiones subnacionales más grandes.

+0

Entiendo que la proyección es más rápida, pero estoy administrando geodatos españoles y no estoy seguro de cómo transformarlos, almacenarlos y procesarlos en GeoDjango. Al mismo tiempo, no estoy seguro si los puntos dados por Google están en SRID 4326 o EPSG 900913 – maraujop

+1

La API de Google regresa y consume coordenadas en EPSG: 4326. Para un sistema proyectado en España, pruebe EPSG: 25831. –

2

Estoy investigando sobre este tema. Por lo que he encontrado, las coordenadas que obtienes de la biblioteca de geopy están en formato SRID 4326, por lo que puedes almacenarlas en un tipo de campo de geometría sin problemas. Esto sería un ejemplo de un modelo usando geometría GeoDjango:

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

    objects = models.GeoManager() 

Por cierto, ser muy cuidadosos para pasar longitud/latitud a la PointField, en ese orden exacto. geopy devuelve coordenadas de latitud/longitud, por lo que deberá invertirlas.

Para transformar puntos en un sistema de coordenadas a otro podemos usar GEOS con GeoDjango. En el ejemplo voy a transformar a un punto en 4326 a la famosa proyección 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)' 

De esta manera podemos almacenar coordenadas en sistemas de proyección, que tendrá un mejor rendimiento de matemáticas. Para mostrar puntos en un mapa de Google en la interfaz del sitio de administración. Podemos usar this great article.

He decidido continuar con los tipos de geografía, y los convertiré en el futuro, en caso de que necesite mejorar el rendimiento.

Cuestiones relacionadas