Meilleure conception pour le prototype Open Source Python / PostGIS

J'écris une application Web gourmande en données qui est livrée via Apache. Ma question est de savoir comment organiser au mieux le traitement étant donné qu'il existe plusieurs options.

J'ai à ma disposition OpenLayers / JQuery / Javascript, PostGIS / Postgresql (avec pgsql), python / psycopg2, php.

La base de données contient environ 3 millions de lignes et le prototype fonctionne actuellement comme suit:

• L'utilisateur clique sur un point de la fenêtre OpenLayers

• Les coordonnées sont envoyées sous forme de requête AJAX à une fonction python sur le serveur

• Actuellement, ma demande est apatride

• Le psycopg2 de Python est utilisé pour appeler une procédure stockée pgsql et un ensemble plus large de valeurs WKT (et un champ de données) sont renvoyés au module python

• Le champ de données est utilisé pour classer les enregistrements WKT en python comme suit: toutes les valeurs WKT sont classées dans l'un des 5 groupes. Environ 1% des valeurs WKT sont réellement modifiées.

• Les cinq ensembles / groupes de WKT sont tamponnés pour créer cinq polygones distincts. J'appelle actuellement une procédure stockée dans la base de données pour ce faire. À son tour, cela utilise simplement ST_BUFFER. (J'ai envisagé d'utiliser Shapely mais je ne suis pas sûr qu'il y aura un avantage en termes de performances car la bibliothèque GEOS est utilisée dans les deux cas ...)

• Enfin, les 5 valeurs de texte WKT sont enveloppées dans une chaîne JSON et renvoyées à OpenLayers pour un rendu sous forme de cinq couches.

Je trouve que les goulots d'étranglement sont la recherche spatiale initiale et la dernière étape de mise en mémoire tampon.

Je suppose que la question est:

Y a-t-il une meilleure façon d'organiser les choses? Par exemple, TOUS les traitements de données devraient-ils être effectués dans PostgreSQL (par exemple avec des curseurs) et est-ce que ce serait une bonne chose en termes de maintenance et de performances? Serait-il préférable d'utiliser un serveur de tuiles pour éviter de passer de longues chaînes WKT au client Web? Comment aborderiez-vous cela?

Goulot d'étranglement tampon

Lorsque vous utilisez ST_Buffer, vous pouvez réduire la complexité de la forme résultante en ajoutant une option num_seg_quarter_circle inférieure. Cela devrait réduire la quantité de traitement lors de la mise en mémoire tampon et lors des opérations suivantes.

Dans la documentation PostGIS:

Généralement, dans PostGIS, vous obtiendrez de meilleures performances si vous exécutez des requêtes sur des tables correctement indexées existantes. Cela vous donne un accès facile à plusieurs optimisations (telles que le clustering). Envisagez de traiter le 1% qui change séparément et de fusionner les deux à la fin.

Ne pensant pas du tout à l'architecture, pour toutes les applications de cartographie Web, vous voulez faire autant de traitement à l'avance. Cela signifie que si vous le pouvez, les tampons doivent être pré-calculés, toutes vos données doivent être dans le SRS de sortie, etc. Évidemment, certaines données et certains calculs doivent être dynamiques.

Je suggère qu'au-delà de Python, vous regardez MapServer et Geoserver pour faire les calculs et produire la sortie. Les deux pourraient produire des tuiles d'image ou une sortie GeoJSON. Les deux applications peuvent utiliser PostGIS comme serveur principal.