Najlepszy projekt dla prototypu Python / PostGIS Open Source

Piszę aplikację internetową intensywnie wykorzystującą dane, która jest dostarczana za pośrednictwem apache. Moje pytanie dotyczy tego, jak najlepiej zorganizować przetwarzanie, biorąc pod uwagę, że istnieje wiele opcji.

Mam do dyspozycji OpenLayers / JQuery / JavaScript, PostGIS / Postgresql (z pgsql), python / psycopg2, php.

Baza danych zawiera około 3 milionów wierszy, a prototyp działa obecnie w następujący sposób:

• Użytkownik klika punkt w oknie OpenLayers

• Współrzędna jest wysyłana jako żądanie AJAX do funkcji python na serwerze

• Obecnie moja aplikacja jest bezpaństwowa

• Psycopg2 Pythona służy do wywoływania procedury składowanej pgsql, a duży zestaw wartości WKT (i pole danych) są zwracane z powrotem do modułu python

• Pole danych służy do kategoryzacji rekordów WKT w pythonie w następujący sposób: wszystkie wartości WKT są podzielone na jedną z 5 grup. Około 1% wartości WKT jest faktycznie zmodyfikowanych.

• Pięć zestawów / grup WKT jest buforowanych w celu utworzenia pięciu różnych wielokątów. Obecnie w tym celu wywołuję procedurę przechowywaną w bazie danych. To z kolei po prostu używa ST_BUFFER. (Zastanawiałem się nad użyciem Shapely, ale nie jestem pewien, czy będzie przewaga wydajności, ponieważ biblioteka GEOS jest używana w obu przypadkach ...)

• Na koniec 5 wartości tekstowych WKT jest zawijanych w łańcuch JSON i wysyłanych z powrotem do OpenLayers w celu renderowania jako pięć warstw.

Uważam, że wąskie gardła to początkowe wyszukiwanie przestrzenne i ostatni etap buforowania.

Myślę, że pytanie brzmi:

Czy istnieje lepszy sposób na zorganizowanie rzeczy? Na przykład, czy WSZYSTKIE przetwarzanie danych powinno odbywać się w PostgreSQL (np. Przy pomocy kursorów) i czy byłoby to dobre z punktu widzenia konserwacji i wydajności? Czy lepiej byłoby użyć serwera kafelków, aby uniknąć przekazywania długich ciągów WKT do klienta WWW? Jak byś to rozwiązał?

Buforowanie wąskiego gardła

Podczas korzystania z ST_Buffer można zmniejszyć złożoność wynikowego kształtu, dodając niższą opcję num_seg_quarter_circle. Powinno to zmniejszyć ilość przetwarzania podczas buforowania i kolejnych operacji.

Z dokumentacji PostGIS:

Zasadniczo w PostGIS uzyskasz lepszą wydajność, jeśli uruchomisz zapytania względem istniejących poprawnie indeksowanych tabel. Zapewnia to łatwy dostęp do kilku optymalizacji (takich jak klastrowanie). Rozważ przetworzenie 1%, który zmienia się osobno, i scalenie dwóch na końcu.

W ogóle nie myśląc o architekturze, w przypadku wszystkich aplikacji do mapowania sieci, chcesz wykonać tyle przetwarzania przed czasem. Oznacza to, że jeśli możesz, bufory powinny być wstępnie obliczone, wszystkie twoje dane powinny znajdować się w wyjściowym SRS itp. Oczywiście niektóre dane i obliczenia muszą być dynamiczne.

Sugeruję, aby poza Pythonem spojrzeć na MapServer i Geoserver, aby wykonać obliczenia i uzyskać dane wyjściowe. Oba mogą generować kafelki obrazu lub dane wyjściowe GeoJSON. Obie aplikacje mogą korzystać z PostGIS jako zaplecza.