Лучший дизайн для прототипа Open Source Python / PostGIS

Я пишу веб-приложение с интенсивным использованием данных, которое поставляется через Apache. Мой вопрос о том, как лучше организовать обработку, учитывая, что есть несколько вариантов.

Я имею в своем распоряжении OpenLayers / JQuery / Javascript, PostGIS / Postgresql (с pgsql), python / psycopg2, php.

База данных содержит около 3 миллионов строк, и в настоящее время прототип работает следующим образом:

• Пользователь нажимает на точку в окне OpenLayers

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

• В настоящее время мое заявление не имеет гражданства

• Psycopg2 Python используется для вызова хранимой процедуры 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 в качестве серверной части.