Arquitetura do Geonode

O núcleo do GeoNode é baseado no framework web Django com mais algumas dependências necessárias para a comunicação com os servidores geoespaciais (GeoServer, pyCSW)

No lado esquerdo você pode ver a lista de entidades definidas no GeoNode e geridos pelo framework Django. Esses objetos serão detalhados em uma seção futuro.

No lado direito temos a lista de serviços disponíveis que permitem o GeoNode se comunicar de forma “social”.

O catálogo GeoNode é intimamente ligado ao GeoServer (ver a parte inferior da figura). O conjunto de dados geoespaciais e os Serviços OGC são implementados e geridos pelo GeoServer. O GeoNode age como um “corretor” para as camadas geoespaciais, acrescentando informações e ferramentas que tornam mais fácil a gestão, catalogação, mapeamento e pesquisa dos conjuntos de dados e metadados.

Graças à estrutura ORM e as bibliotecas auxiliares do Python, o GeoNode está constantemente alinhado com o catálogo do GeoServer. Um módulo de segurança ad-hoc permite que os dois módulos para interagir de forma estrita e compartilhar regras de segurança e permissões.

GeoNode é baseado no Django que é uma framework web de alto nível desenvolvida em Python que incentiva o desenvolvimento rápido, com praticidade, testes e código limpo. Django é baseado na arquitetura padrão Model View Controller (MVC), e, como tal, modelos GeoNode camadas, mapas e outros módulos foram desenvolvidos com base nos modelos de banco de dados que o Django implementa. Esses modelos são utilizados via ORM do Django contendo a lógica de negócios do GeoNode e são usados ​​para conduzir modelos HTML para exibir as páginas da web dentro do aplicativo.

Model representa dados de aplicativos e fornece funcionalidade ricas de ORM (Object Relational Mapping).

Views são uma renderização do modelo usados frenquentemente em conjunto com os templates para produzir as páginas do aplicativo.

No Django, a parte Controller é alvo de discussões por engenheiros de software. De acordo com a definição padrão, o controlador é a camada ou componente através do qual o usuário interage com o modelo. Mas no Django sua definição é um pouco diferente:

MVP

Model, View, Presenter

No MVP, o Presenter contém a lógica de negócios da interface com o usuário UI. Todas as invocações da View são delegadas diretamente para o Presenter. O Presenter também é desacoplado da View e conversa com ela através de uma interface. Isto permite o mocking da View em testes de unidade. Um atributo comum de MVP é que existe uma grande quantidade de dispatching de mão dupla. Por exemplo, quando alguém clica no botão Save, os handlers manipuladores de evento delega ao método OnSave do Presenter. Uma vez que a gravação for concluída, o Presenter, então, chamar de volta a View através da sua interface de modo que a View pode exibir que o save foi concluído com sucesso.

MVP tende a ser um padrão muito natural para separar os papeis do Presenter e da View em formulários web.

Existem duas variações primárias dessa abordagem ( Você pode descobrir mais sobre ambas as variantes.)

View passiva: A View é tão idiota quanto possível e contém quase zero lógica do negócio (ou qualquer outro tipo de lógica). O Presenter é um intermediário que se comunica com a View e o Model. A View e Model são completamente blindados um do outro. O modelo pode gerar eventos, mas o Presenter pode registra-los para atualizar a View. Nessa variação os dados não são vinculadas diretamente, em vez disso a View expõe as propriedades setter que o Presenter usa para definir os dados. Todo Estado é gerido no Presenter e não na View.

Pro: Máxima capacidade para realizar testes de código; separação completa da View e Model

Con: mais trabalhoso (por exemplo, todos setters que devem ser implementados) já que você deve fazer a ligação com os dados diretamente.

Supervisão Controlador: A View liga-se ao modelo diretamente . Neste caso, é trabalho do Presenter ligar a View e o Model. O Presenter também conterá a lógica para inputs do usuário, como apertar um botão, navegação, etc.

Pro: potencializando a ligação de dados a quantidade de código é reduzida. Con: há menos superfície testável (por causa da ligação de dados), e há menos de encapsulamento na View já que ela fala diretamente ao modelo.

MVC

Model, View, Controller

No MVC, o controlador é responsável por determinar qual View é apresentada em resposta a qualquer ação, incluindo quando o aplicativo é carregado.

Isso difere do MVP onde as ações são roteatas através da View para o Presenter. No MVC, cada ação na View correlaciona-se com uma chamada para um controlador juntamente com uma ação. Na web cada ação envolve uma chamada para uma URL da qual existe um controlador que responde. Uma vez que o controlador tenha concluído seu processamento, ele irá retornar a view correta.

Ação na View

•     Chamada para Controlador
•     Logic Controller
•     Controlador devolve o View.

Uma outra grande diferença sobre MVC é que a View não se liga diretamente ao modelo. A view apenas renderiza e é completamente sem estado. Em implementações de MVC a View costuma não ter qualquer lógica no código. Ao contrário do MVP onde o Presenter nunca será invocado se a View não fizer seu papel.

mais: : http://reinout.vanrees.org/weblog/2011/12/13/django-mvc-explanation.html

Web Server Gateway Interface (whis-gey)

Esta é uma especificação python para suportar uma interface comum entre todos os vários frameworks web e um servidor (Apache, por exemplo).

Isso permite que qualquer software compatível com WSGI a ser hospedado em qualquer servidor compatível com WSGI. Para a maioria do desenvolvimento do GeoNode os detalhes da presente especificação podem ser ignorados.

Mais: http://en.wikipedia.org/wiki/Wsgi

GeoNode usa GeoServer para a prestação de serviços OGC.

Na sua essência, GeoNode fornece uma plataforma baseada em padrões para permitir acesso integrado, programático aos seus dados através do OGC Web Services, que são essenciais e necessárias para implantar uma infra-estrutura de dados espaciais OGC-compliant (SDI).

Estes Web Services permitem, descoberta, visualização, acesso e o compartilhamento dos seus dados, tudo sem necessariamente ter que interagir diretamente com seu site.

• GeoNode configura e opera o GeoServer através da API REST
• GeoNode recupera e armazena informações espaciais do GeoServer. Isso inclui links dos serviços OGC, metadados espaciais, e informações de atributo.

• Em resumo, GeoServer contém os dados de camada, e o Geonode estende os metadados presentes no GeoServer com a seus próprios dados.
• GeoNode pode descobrir camadas existentes publicados em um GeoServer via documento de capacidades WMS.
• GeoServer delega autenticação e autorização para GeoNode.
• Dados enviados para o GeoNode são primeiro processados no GeoNode e, finalmente publicado para GeoServer.

• operam através de HTTP (GET, POST)
• fornece API formalizada e aceita
• fornece formatos formalizados e aceitos

Os Serviços Web OGC fornecidos pelo GeoNode têm uma base de implementação madura e tem uma abordagem multi-aplicação propícia para integração. Isto significa que, do ponto de vista de um desenvolvedor, já existem inúmeros pacotes GIS , ferramentas e webapps (proprietária, livre, open source) que suporte nativo OGC Web Services.

Existem inúmeras maneiras interagir com os serviços Web OGC do GeoNode:

• Aplicações GIS para desktop
• Aplicativo baseado na web
• Bibliotecas cliente/toolkits
• Desenvolvimento personalizado

Seu GeoNode lista Serviços Web OGC e suas URLs no endereço http://localhost:8000/developer . Você pode usar essas APIs diretamente para interagir com o seu GeoNode.

As secções seguintes descrevem brevemente os serviços Web OGC fornecidos pelo GeoNode.

WMS fornece uma API para recuperar imagens de mapas (PNG, JPEG, etc.) de dados geoespaciais. WMS é adequado para visualização quando o acesso aos dados brutos não é um requisito.

WFS fornece fornece uma API para recuperar dados vetoriais geoespaciais. WFS é adequado para consulta direta e acesso a características geográficas.

WCS fornece fornece uma API para recuperar dados raster geoespaciais. WCS é adequado para acesso direto a imagens de satélite, DEM, etc.

CSW fornece uma interface para publicar e pesquisa metadados (dados sobre dados). CSW é adequado para catalogar dados geoespaciais e torná-lo detectável para permitir a visualização e acesso.

WMTS fornece uma API para recuperação de mapas e tiles pré-renderizados de dados geoespaciais.

WMC fornece um formato para salvar e visualizações de mapas e estado do aplicativo via XML. Isso permite, por exemplo, que um usuário salve o seu aplicativo web no WMC e compartilhe.

Mais: http://geoserver.org

O Geonode é configurado para utilizar PostgreSQL/PostGIS em produção. Em desenvolvimento e em modos de teste, muitas vezes, um banco de dados SQLite é usado. Este último não é sugerido para a produção.

• O banco de dados armazena configurações e informações do aplicativo. Isso inclui usuários, camadas, mapas, etc.

• Recomenda-se que GeoNode seja configurado para usar o PostgresSQL/PostGIS para armazenar dados vetoriais também. Enquanto servir camadas diretamente do shapefile permite um desempenho adequado em muitos casos, seu armazenamento no banco de dados permite um melhor desempenho, especialmente ao usar regras de estilo complexas baseadas em atributos.

GeoNode é construído com pycsw incorporado como o componente de servidor CSW padrão. Mas é possível utilizar outros, como geonetwork e deegree:

http://docs.geonode.org/en/master/tutorials/admin/csw_settings/

Como o pycsw é incorporado ao GeoNode, camadas publicados dentro GeoNode são publicados automaticamente para pycsw e detectável através de CSW. Nenhuma configuração ou ações adicionais são obrigadas a publicar camadas, mapas e documentos para pycsw.

O endpoint do CSW do GeoNode fica disponível em http://localhost:8000/catalog/csw. Veja http://docs.pycsw.org/en/latest/tools.html para uma lista de clientes e ferramentas CSW.

GeoNode fornece uma série de facilidades para interatividade no navegador da web construída em cima de vários frameworks JavaScript de alta qualidade:

• Bootstrap para a interface do usuário front-end do GeoNode e interação com o usuário comum.
• Bower para gestão de pacotes front-end do GeoNode.
• ExtJS para a construção da interface do usuário e os dados de acesso baseado em componentes
• OpenLayers para o mapeamento interativo e outras operações geoespaciais
• GeoExt para integrar ExtJS com OpenLayers
• Grunt para automação de tarefas front-end.
• GXP para fornecer algumas facilidades de alto-nível para o build em cima do GeoExt, bem como melhorar a integração com GeoServer.
• jQuery à manipulação abstrata de javascript, manipulação de eventos, animação e Ajax.

GeoNode utiliza módulos de aplicações específicas para lidar com as páginas e serviços que são exclusivos do GeoNode.

São eles:

• A classe GeoNode Mixin que fornece GeoExplorer com os métodos necessários para funcionar corretamente no GeoNode. A classe é responsável por verificar as permissões, recuperar e enviar o token CSRF e autenticação do usuário.
• Um módulo de pesquisa responsável pela funcionalidade de pesquisa em todo o site da GeoNode.
• Um upload e um módulo de estado para apoiar o upload de arquivos.
• Os arquivos de modelo para gerar seções html comumente usados.
• Um módulo de teste de front-end para testar javascript.

Os seguintes conceitos são particularmente importantes para o desenvolvimento em cima do framework JavaScript do GeoNode.

• Componentes Extjs para lidar com funcionalidade mais interativas em páginas da web. Por exemplo, o scrollable/sortable/filterable na página de pesquisa padrão é um componente Grid. Enquanto GeoNode usa alguns componentes personalizados, a familiaridade com a idéia de componentes utilizados por ExtJS é aplicável em desenvolvimento GeoNode.

• Os Viewers exibem mapas interativos em páginas da web, opcionalmente decorados com controles ExJs para barras de ferramentas, seleção de camada, etc. Viewers no GeoNode usam a classe base GeoExplorer, que se constrói em cima do Viewer GXP para fornecer alguma funcionalidade comum, como o respeito as configurações de todo o site para camadas de fundo. Os Viewers podem ser utilizados como componentes embutidos em páginas, ou eles podem ser aplicações JavaScript de página inteira.

• Os controles são ferramentas para uso em mapas OpenLayers (como um controle à mão livre para desenhar novas geometrias em um mapa, ou um controle de identificação para obter informações sobre os recursos individuais em um mapa.) GeoExt fornece ferramentas para usar esses controles como ExtJS “Actions” - operações que podem ser invocadas como botões ou opções de menu ou associados a outros eventos.