Qual é a maneira mais rápida (em termos de desempenho) de atender aos recursos do PostGIS?

Estou interessado na maneira mais rápida de atender aos recursos do PostGIS. Posso encontrar várias melhorias e alternativas do WMS (MapProxy, TileCache, Mapnik ...), mas não tantas melhorias e alternativas de código aberto do WFS. Não estou interessado em ladrilhos, mas em polígonos sobre minha camada base. Servido rapidamente.

Você poderia me indicar a direção certa?

Atualizar:

Esqueci de mencionar que meu aplicativo mostra informações cadastrais. E os polígonos cadastrais devem ser selecionáveis ​​(não editáveis, eles são destacados apenas quando você clica neles).

Estou usando agora uma mistura de objetos GeoJSON gerando WMS + Django quando o usuário clica em uma parte do mapa, para evitar situações como milhares de polígonos ao mesmo tempo no cliente (OpenLayers).

Não sei se estou no caminho certo (devo evitar situações potencialmente difíceis, como milhares de pols no cliente, processando-as via WMS ou qualquer outra solução? Devo melhorar a maneira como os polígonos são servidos?)

Que tal simplificar geometrias?

http://www.bostongis.com/postgis_simplify.snippet

/programming/1849928/how-to-intelligently-degrade-or-smooth-gis-data-simplifying-polygons

Ou talvez uma combinação de WFS, WFS com recursos simplificados e WMS?

O GeoServer fornece uma configuração do usuário para controlar o número de casas decimais nas geometrias que foram inseridas para acelerar a veiculação do WFS.

Verifique também se o servidor está compactando a saída apenas se o seu cliente puder descompactá-la com eficiência.

Finalmente, ouvi coisas boas sobre o pequeno OWS em termos de velocidade.

O cache do WFS pode atender às suas necessidades. Até onde eu sei, existem duas soluções de código aberto que fornecem cache WFS: TileStache e GeoWebCache .

Na página inicial do TileStache, na seção de recursos, diz-se "Gera blocos vetoriais a partir de fontes de dados OGR no GeoJSON utilizáveis ​​no Polymaps"

O GeoWebCache possui alguns recursos de armazenamento em cache do WFS desde a versão 1.1.0 (a atual é a 1.2.6):

GeoWebCache 1.1.0 (finalmente) lançado

...

1.c Cache básico do WFS O GeoWebCache 1.1.0 suporta o cache básico do WFS. Os resultados das consultas são armazenados no disco, atualmente não há funções para inspecioná-las ou removê-las programaticamente. O algoritmo se baseia em hashes computados e não verifica a exclusividade, portanto, há uma chance minúscula de colisão. A motivação para esse desenvolvimento foi o formato de saída SHP-ZIP (zipado shapefile) no GeoServer. Esses arquivos podem ser enormes e tremendamente caros de calcular. Esse serviço WFS, no estado atual, não se destina a ser usado em casos mais complicados.

http://old.nabble.com/GeoWebCache-1.1.0-(finally)-released-td22870524.html

Infelizmente, nunca trabalhei com o TileStache nem o GeoWebCache, por isso não posso compartilhar nenhuma experiência sobre o cache do WFS.

Estou desenvolvendo um grande web-gis, trabalho com muitos dados (cerca de 700.000 recursos por camada) A única solução é a que você está fazendo, o WMS para renderizar os recursos e o WFS para obter informações sobre os recursos. O que estou fazendo (com bom desempenho) é:

• Geoserver (com biblioteca JAI nativa )
• Quando o usuário clica no mapa, um wms getfeatureinfo é usado para obter as informações (forma e dados) do recurso selecionado (aqui você deve implementar alguma função de filtragem, se houver recursos sobrepostos)
• O resultado de getFeatureInfo é adicionado como recurso em outra camada para simular o "destaque da seleção"

Servidor DRAM de estado sólido

http://en.wikipedia.org/wiki/Solid-state_drive#DRAM-based

"A demanda por bit DRAM proveniente do setor de servidores subirá 93,7% no ano no segundo semestre de 2011"

fonte: http://www.digitimes.com/Reports/Report.asp?datePublish=2011/08/16&pages=PD&seq=206