Найкраща конструкція для прототипу Open Source Python / PostGIS

Я пишу веб-додаток, що інтенсивно використовує дані, що постачається через apache. Моє запитання - як найкраще організувати обробку, враховуючи, що існує кілька варіантів.

У мене в розпорядженні OpenLayers / JQuery / Javascript, PostGIS / Postgresql (з pgsql), python / psycopg2, php.

База даних містить близько 3 мільйонів рядків, і прототип в даний час працює наступним чином:

• Користувач натискає на точку у вікні OpenLayers

• Координата надсилається як запит AJAX через функцію python на сервері

• Наразі моя заява без громадянства

• Python's psycopg2 використовується для виклику збереженої процедури pgsql, а великий набір значень WKT (і поля даних) повертається назад до модуля python

• Поле даних використовується для класифікації записів WKT в python наступним чином: всі значення WKT класифікуються в одну з 5 груп. Близько 1% значень WKT фактично модифіковані.

• П'ять наборів / груп WKT буферизовані для створення п'яти різних багатокутників. Зараз я закликаю збережену процедуру в базі даних, щоб це зробити. Це в свою чергу просто використовує ST_BUFFER. (Я розглядав можливість використання Shapely, але не впевнений, що буде перевага для продуктивності, оскільки бібліотека GEOS використовується в будь-якому випадку ...)

• Нарешті 5 текстових значень WKT загортаються в рядок JSON і відправляються назад у OpenLayers для візуалізації у вигляді п'яти шарів.

Я знаходжу, що вузькі місця є початковим просторовим пошуком і завершальним етапом буферизації.

Я думаю, Питання:

Чи є кращий спосіб оформити речі? Наприклад, чи слід ВСЕ обробку даних проводити в PostgreSQL (наприклад, за допомогою курсорів), і чи це буде добре в плані обслуговування та продуктивності? Було б краще використовувати сервер плитки, щоб уникнути передачі довгих рядків WKT веб-клієнту? Як би ви вирішили це?

Вузьке місце буферизації

Використовуючи ST_Buffer, ви можете зменшити складність отриманої форми, додавши нижню опцію num_seg_quarter_circle. Це повинно зменшити обробку при буферизації та в наступних операціях.

З документації PostGIS:

Як правило, в PostGIS ви отримаєте кращу ефективність, якщо будете виконувати запити щодо існуючих правильно індексованих таблиць. Це дає вам легкий доступ до кількох оптимізацій (наприклад, кластеризації). Розглянемо обробку 1%, що змінюється окремо, і об'єднання двох в кінці.

Зовсім не замислюючись про архітектуру, для всіх додатків веб-картографічних програм ви хочете виконати якнайбільше обробки раніше часу. Це означає, що якщо ви можете, буфери повинні бути попередньо обчислені, всі ваші дані повинні бути у вихідному SRS тощо. Очевидно, деякі дані та обчислення повинні бути динамічними.

Я пропоную, що за межами Python, ви подивитесь на MapServer та Geoserver, щоб зробити розрахунки та отримати результат. Обидва вони могли створювати плитки зображення або вихід GeoJSON. Обидва програми можуть використовувати PostGIS в якості зворотного кінця.